بخش دوم :

خیلی از CVEها در نهایت vulnerability واقعی نیستند. فقط bug معمولی‌ اند که اشتباه گزارش شده‌اند و وقت همه را تلف می‌کنند.

گزارش‌ دهی نادرست آسیب‌ پذیری‌ ها

اشتباه گرفتن مکرر بین bugs و vulnerabilities می‌تواند منجر به گزارش‌ دهی نادرست آسیب‌ پذیری‌ها شود. برای مثال، هم پروژهٔ curl و هم پروژهٔ Postgres گزارش‌ های آسیب‌پذیری‌ هایی را رد کرده‌اند که در واقع bug بودند، نه vulnerability واقعی.

مثال اول: CVE-2020-19909 در curl
یکی از موارد بحث‌برانگیز، CVE-2020-19909 است. توصیف اولیهٔ آن به این شکل بود:

آسیب‌پذیری integer overflow در فایل tool_operate.c در نسخهٔ curl 7.65.2 به دلیل پذیرش یک مقدار بسیار بزرگ به عنوان retry delay.

ا Daniel Stenberg (توسعه‌دهندهٔ اصلی curl) در پست وبلاگی با عنوان «CVE-2020-19909 is everything that is wrong with CVEs» توضیح می‌ دهد که این integer overflow در گزینهٔ خط فرمان --retry-delay رخ می‌دهد. این گزینه تعیین می‌کند curl قبل از retry کردن یک درخواست ناموفق، چند ثانیه منتظر بماند.

اگر کاربر در یک سیستم ۶۴ بیتی عددی مانند 18446744073709552 وارد کند، به دلیل overflow، curl آن را به صورت عدد 384 تفسیر می‌ کند.

این سناریو یک weakness ناشی از integer overflow را برآورده می‌ کند و حتی ممکن است در برخی شرایط exploitable به نظر برسد (مثلاً اگر سیستمی ورودی کاربر را به curl پاس دهد تا درخواست‌ های سمت سرور انجام دهد). اما واقعیت این است که این مسئله از هیچ security boundary مهمی عبور نمی‌کند. حتی اگر مهاجمی بتواند از آن اکسپلویت کند و باعث شود curl درخواست‌ های ناموفق را زودتر از حد انتظار retry کند، به سختی می‌توان آن را یک مسئلهٔ امنیتی واقعی دانست.

در نهایت، رکورد CVE اصلاح‌شده به این شکل به‌روزرسانی شد:

توجه: بسیاری از طرف‌ ها گزارش میکنند که این موضوع اثر امنیتی مستقیمی روی کاربر curl ندارد؛ با این حال، ممکن است باعث denial of service برای سیستم‌ ها یا شبکه‌ های مرتبط شود، اگر مثلاً --retry-delay به عنوان مقداری بسیار کوچک‌تر از مقدار مورد نظر تفسیر شود.

این سناریو بسیار بعید است، زیرا overflow فقط زمانی رخ می‌ دهد که کاربر عمداً بخواهد curl صدها روز (یا حتی بیشتر) قبل از retry کردن یک خطای موقتی منتظر بماند.

علاوه بر این، در استفادهٔ عادی توسط کاربر محلی، این مسئله اصلاً از security boundary عبور نمی‌کند؛ چون کاربر در هر صورت کنترل کامل روی --retry-delay دارد.

مثال دوم: CVE-2020-21469 در Postgres
استدلال مشابهی برای CVE-2020-21469 در PostgreSQL نیز صدق می‌کند. توصیف اولیهٔ این CVE چنین بود:

در PostgreSQL 12.2 مشکلی کشف شده که به مهاجمان اجازه می‌ دهد با ارسال مکرر سیگنال SIGHUP باعث denial of service شوند.

توسعه‌دهندگان Postgres در پاسخی با عنوان «CVE-2020-21469 is not a security vulnerability» تأکید کردند که اکسپلویت از این مسئله نیازمند دسترسی سطح بالا است، مانند:

داشتن دسترسی PostgreSQL superuser (کاربر postgres)

داشتن مجوز اجرای pg_reload_conf از طرف superuser

دسترسی به یک کاربر privileged در سطح سیستم‌عامل

با این سطح دسترسی، مهاجم به راحتی و بدون نیاز به هیچ exploit خاصی می‌تواند دیتابیس را متوقف کند (یا کارهای بسیار مخرب‌ تری انجام دهد). بنابراین، مطرح کردن آن به عنوان vulnerability معنادار نیست.

جمع‌بندی:

همه vulnerabilityها bug هستند، اما همه bugها vulnerability نیستند. قبل از گزارش CVE، حتماً بررسی کنید آیا واقعاً از security boundary عبور می‌کند یا خیر.

این تفاوت‌ ها را در ذهن داشته باشید تا وقتتان را صرف مسائل بی‌ اهمیت نکنید.

این پست رو ذخیره کن و برای دوستانت فوروارد کن!

بخش یکم
@PfkSecurity