آسیب‌پذیری اجرای کد در موزیلا NSS هنگام پردازش گواهی‌ها

یک آسیب‌پذیری حیاتی (CVE-2021-43527) در مجموعه NSS (سرویس‌های امنیتی شبکه) از کتابخانه‌های رمزنگاری توسعه‌یافته توسط موزیلا شناسایی شده است که می‌تواند منجر به اجرای کد مهاجم در هنگام پردازش امضاهای دیجیتال DSA یا RSA-PSS شود که با استفاده از روش رمزگذاری DER (قوانین رمزگذاری متمایز). این مشکل با کد BigSig در NSS 3.73 و NSS ESR 3.68.1 حل شده است. به‌روزرسانی‌های بسته در توزیع‌ها برای Debian، RHEL، Ubuntu، SUSE، Arch Linux، Gentoo، FreeBSD در دسترس هستند. هنوز هیچ به روز رسانی برای فدورا موجود نیست.

مشکل در برنامه‌هایی رخ می‌دهد که از NSS برای مدیریت CMS، S/MIME، PKCS #7 و PKCS #12 امضای دیجیتال یا هنگام تأیید گواهی‌ها در اجرای TLS، X.509، OCSP و CRL رخ می‌دهد. این آسیب‌پذیری می‌تواند در برنامه‌های کلاینت و سرور مختلف که از TLS، DTLS و S/MIME پشتیبانی می‌کنند، کلاینت‌های ایمیل و نمایشگرهای PDF که از فراخوانی NSS CERT_VerifyCertificate() برای تأیید امضای دیجیتال استفاده می‌کنند، ظاهر شود.

LibreOffice، Evolution و Evince به عنوان نمونه هایی از برنامه های آسیب پذیر ذکر شده اند. به طور بالقوه، مشکل ممکن است پروژه هایی مانند Pidgin، Apache OpenOffice، Suricata، Curl، Chrony، Red Hat Directory Server، Red Hat Certificate System، mod_nss برای سرور http Apache، Oracle Communications Messaging Server، Oracle Directory Server Enterprise Edition را نیز تحت تاثیر قرار دهد. با این حال، این آسیب‌پذیری در مرورگر فایرفاکس، تاندربرد و تور که از یک کتابخانه جداگانه mozilla::pkix که در NSS نیز موجود است، برای تأیید استفاده می‌کنند، ظاهر نمی‌شود. مرورگرهای مبتنی بر Chromium (مگر اینکه به طور خاص با NSS ساخته شده باشند)، که تا سال 2015 از NSS استفاده می کردند، اما سپس به BoringSSL تغییر مکان دادند، نیز تحت تأثیر این مشکل قرار نمی گیرند.

این آسیب‌پذیری به دلیل یک خطا در کد تأیید گواهی در تابع vfy_CreateContext از فایل secvfy.c ایجاد می‌شود. این خطا هم زمانی رخ می دهد که مشتری یک گواهی را از سرور می خواند و هم زمانی که سرور گواهی های مشتری را پردازش می کند. هنگام تأیید یک امضای دیجیتال رمزگذاری شده با DER، NSS امضا را به یک بافر با اندازه ثابت رمزگشایی می کند و بافر را به ماژول PKCS #11 ارسال می کند. در طول پردازش بیشتر، اندازه به اشتباه برای امضاهای DSA و RSA-PSS بررسی می شود، که منجر به سرریز بافر اختصاص داده شده برای ساختار VFYContextStr اگر اندازه امضای دیجیتال از 16384 بیت بیشتر شود (2048 بایت برای بافر تخصیص داده می شود، اما بررسی نمی شود که امضا می تواند بزرگتر باشد)).

کد حاوی این آسیب‌پذیری را می‌توان به سال 2003 ردیابی کرد، اما تا زمانی که در سال 2012 بازسازی انجام شد، خطری ایجاد نکرد. در سال 2017، همین اشتباه هنگام اجرای پشتیبانی RSA-PSS انجام شد. برای انجام یک حمله، نیازی به تولید منابع فشرده کلیدهای خاص برای به دست آوردن داده های لازم نیست، زیرا سرریز در مرحله قبل از بررسی صحت امضای دیجیتال رخ می دهد. بخشی از داده‌ها که فراتر از مرزها است، در یک ناحیه حافظه حاوی اشاره‌گرهایی به توابع نوشته می‌شود، که ایجاد اکسپلویت‌های کاری را ساده می‌کند.

این آسیب‌پذیری توسط محققان Google Project Zero در حین آزمایش روش‌های آزمایش فازی جدید کشف شد و نشان‌دهنده خوبی است از اینکه چگونه آسیب‌پذیری‌های بی‌اهمیت می‌توانند برای مدت طولانی در یک پروژه شناخته شده به طور گسترده مورد آزمایش قرار نگیرند:

• کد NSS توسط یک تیم امنیتی با تجربه با استفاده از تکنیک‌های تست و تجزیه و تحلیل خطا نگهداری می‌شود. چندین برنامه برای پرداخت پاداش های قابل توجه برای شناسایی آسیب پذیری ها در NSS وجود دارد.
• NSS یکی از اولین پروژه هایی بود که به ابتکار oss-fuzz گوگل پیوست و همچنین در سیستم تست فازی مبتنی بر libFuzzer موزیلا آزمایش شد.
• کد کتابخانه بارها در تحلیلگرهای استاتیک مختلف بررسی شده است، از جمله اینکه از سال 2008 توسط سرویس Coverity نظارت شده است.
• تا سال 2015، NSS در گوگل کروم استفاده می شد و به طور مستقل توسط تیم گوگل و مستقل از موزیلا تایید می شد (از سال 2015، کروم به BoringSSL تغییر مکان داد، اما پشتیبانی از پورت مبتنی بر NSS همچنان باقی است).

مشکلات اصلی که به دلیل آن مشکل برای مدت طولانی کشف نشد:

• کتابخانه مدولار NSS و آزمایش فازی نه به عنوان یک کل، بلکه در سطح اجزای جداگانه انجام شد. به عنوان مثال، کد رمزگشایی DER و پردازش گواهی ها به طور جداگانه بررسی شد - در حین فاز زدن، گواهینامه ای می توانست به دست آید که منجر به بروز آسیب پذیری مورد نظر شود، اما بررسی آن به کد تأیید نرسید و مشکل به دست نیامد. خود را آشکار کند.
• در طول آزمایش فازی، محدودیت‌های سختی بر روی اندازه خروجی (10000 بایت) در غیاب محدودیت‌های مشابه در NSS تعیین شد (بسیاری از ساختارها در حالت عادی می‌توانند اندازه بیش از 10000 بایت داشته باشند، بنابراین داده‌های ورودی بیشتری برای شناسایی مشکلات مورد نیاز بود). . برای راستی‌آزمایی کامل، حد مجاز باید 224-1 بایت (16 مگابایت) باشد که با حداکثر اندازه گواهی مجاز در TLS مطابقت دارد.
• تصور غلط در مورد پوشش کد تست فازی. کد آسیب پذیر به طور فعال مورد آزمایش قرار گرفت، اما با استفاده از فازرهایی که قادر به تولید داده های ورودی لازم نبودند. به عنوان مثال، fuzzer tls_server_target از مجموعه ای از گواهی های آماده از پیش تعریف شده استفاده می کند که بررسی کد تأیید گواهی را فقط به پیام های TLS و تغییرات وضعیت پروتکل محدود می کند.

منبع: opennet.ru