الأخبار عن تحديد نقاط الضعف الحرجة (مدرج بالفعل ضمن CVE-2021-43527) en مجموعة مكتبات التشفير NSS (خدمات أمن الشبكة) من Mozilla قد يؤدي إلى تنفيذ تعليمات برمجية ضارة عند معالجة التوقيعات الرقمية DSA أو RSA-PSS المحددة باستخدام DER (قواعد التشفير المميزة).
المشكلة يتجلى في التطبيقات التي تستخدم 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 وغيرها.
في الوقت نفسه ، لا تظهر الثغرة الأمنية في متصفح Firefox و Thunderbird و Tor، والتي تستخدم مكتبة mozilla :: pkix منفصلة للتحقق ، والتي تعد أيضًا جزءًا من NSS. ال المتصفحات القائمة على Chrome (ما لم يتم تجميعها على وجه التحديد باستخدام 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 واختبارات التشويش بالكامل ، ولكن على مستوى المكون الفردي.
- على سبيل المثال ، تم التحقق من رمز فك تشفير DER ومعالجة الشهادات بشكل منفصل ؛ في سياق الغموض ، كان من الممكن الحصول على شهادة ، مما أدى إلى ظهور الثغرة الأمنية المعنية ، لكن التحقق منها لم يصل إلى رمز التحقق ولم يتم الكشف عن المشكلة.
- أثناء اختبارات التشويش ، تم وضع حدود صارمة على حجم الإخراج (10,000 بايت) في حالة عدم وجود مثل هذه القيود في NSS (يمكن أن تكون العديد من الهياكل في الوضع العادي أكبر من 10,000 بايت ، وبالتالي ، لتحديد المشكلات ، يلزم المزيد من بيانات الإدخال ). للتحقق الكامل ، يجب أن يكون الحد 2 24-1 بايت (16 ميجابايت) ، وهو ما يتوافق مع الحد الأقصى لحجم الشهادة المسموح به في TLS.
- مفهوم خاطئ حول تغطية الكود عن طريق اختبارات التشويش. تم اختبار الكود الضعيف بشكل نشط ، ولكن باستخدام الصمامات ، التي لم تكن قادرة على توليد بيانات الإدخال المطلوبة. على سبيل المثال ، استخدم fuzzer tls_server_target مجموعة محددة مسبقًا من الشهادات الجاهزة ، والتي حدت من التحقق من رمز التحقق من الشهادة لرسائل TLS وتغييرات حالة البروتوكول فقط.
وأخيرا، الجدير بالذكر أنه تم إصلاح مشكلة الاسم الرمزي BigSig في NSS 3.73 و NSS ESR 3.68.1 وقد تم بالفعل إصدار تحديثات الحل في شكل حزمة في توزيعات مختلفة: Debian و RHEL و Ubuntu و SUSE و Arch Linux و Gentoo و FreeBSD وما إلى ذلك.
إذا كنت تريد معرفة المزيد عنها ، يمكنك استشارة الرابط التالي.