تم التعرف على ثغرة خطيرة (CVE-2021-43527) في مجموعة مكتبات التشفير NSS (Network Security Services) التي طورتها Mozilla، والتي يمكن أن تؤدي إلى تنفيذ تعليمات برمجية للمهاجم عند معالجة التوقيعات الرقمية 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 Certified System وmod_nss لخادم Apache http وOracle Communications Messaging Server وOracle Directory Server Enterprise Edition. ومع ذلك، لا تظهر الثغرة الأمنية في متصفحات Firefox وThunderbird وTor، التي تستخدم مكتبة mozilla::pkix منفصلة، مضمنة أيضًا في NSS، للتحقق. المتصفحات المستندة إلى Chromium (ما لم يتم إنشاؤها خصيصًا باستخدام NSS)، والتي استخدمت NSS حتى عام 2015، ثم تحولت بعد ذلك إلى 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 أحد المشاريع الأولى التي انضمت إلى مبادرة Google oss-fuzz وتم اختباره أيضًا في نظام اختبار الزغب القائم على libFuzzer من Mozilla.
- تم فحص كود المكتبة عدة مرات في العديد من المحللين الثابتين، بما في ذلك مراقبته بواسطة خدمة Coverity منذ عام 2008.
- حتى عام 2015، تم استخدام NSS في Google Chrome وتم التحقق منه بشكل مستقل من قبل فريق Google بشكل مستقل عن Mozilla (منذ عام 2015، تحول Chrome إلى BoringSSL، ولكن يظل دعم المنفذ المستند إلى NSS قائمًا).
المشاكل الرئيسية التي بسببها ظلت المشكلة غير مكتشفة لفترة طويلة:
- لم يتم تنفيذ مكتبة NSS المعيارية واختبار التشويش ككل، ولكن على مستوى المكونات الفردية. على سبيل المثال، تم فحص رمز فك تشفير DER ومعالجة الشهادات بشكل منفصل - أثناء التشويش، كان من الممكن الحصول على شهادة من شأنها أن تؤدي إلى ظهور الثغرة الأمنية المعنية، لكن فحصها لم يصل إلى رمز التحقق ولم تحدث المشكلة تكشف عن نفسها.
- أثناء اختبار التشويش، تم وضع قيود صارمة على حجم الإخراج (10000 بايت) في غياب قيود مماثلة في NSS (يمكن أن يكون حجم العديد من الهياكل في الوضع العادي أكثر من 10000 بايت، لذلك كانت هناك حاجة إلى المزيد من بيانات الإدخال لتحديد المشاكل) . للتحقق الكامل، يجب أن يكون الحد 224-1 بايت (16 ميجابايت)، وهو ما يتوافق مع الحد الأقصى لحجم الشهادة المسموح به في TLS.
- فكرة خاطئة حول تغطية كود اختبار الزغب. تم اختبار التعليمات البرمجية الضعيفة بشكل نشط، ولكن باستخدام أدوات غامضة لم تتمكن من إنشاء بيانات الإدخال الضرورية. على سبيل المثال، استخدم fuzzer tls_server_target مجموعة محددة مسبقًا من الشهادات الجاهزة، مما قصر التحقق من رمز التحقق من الشهادة على رسائل TLS وتغييرات حالة البروتوكول فقط.
المصدر: opennet.ru