💥 إيجاد الثغرة واستغلالها

يكمن السبب الجذري لـ CVE-2025-3052 في الاستخدام غير الآمن لبيانات مقروءة من متغير NVRAM دون التحقق منها. وتحديدًا:

• يسترجع تطبيق UEFI قيمة متغير NVRAM المسمى IhisiParamBuffer.
• تُعامَل هذه القيمة كمؤشر موثوق وتُخزَّن في متغير عام على العنوان 0xf7a0.
• ينفّذ الكود لاحقًا عملية كتابة في الذاكرة عند global + 0x18، مضبطًا ذلك العنوان على الصفر.
• تتبع ذلك عمليات كتابة إضافية، جميعها مستمدة من نفس قيمة NVRAM التي يتحكم بها المهاجم.
• لا يُطبَّق أي فحص للحدود أو تحقق من السلامة أو ضبط للوصول في أي نقطة.

ونتيجة لذلك، يكتسب المهاجم القادر على التحكم في متغير IhisiParamBuffer القدرة على التأثير في مكان حدوث عمليات الكتابة هذه في الذاكرة. ورغم أن بدائية الكتابة مقيّدة إلى حد ما، إذ تتيح عادةً كتابة أصفار أو ثوابت صغيرة إلى عنوان عشوائي، فإنها لا تزال قوية بما يكفي لإفساد حالة البرامج الثابتة الحرجة.

في إثبات المفهوم الخاص بـ Binarly، يستهدف الهجوم المتغير العام gSecurity2، الذي يحمل مؤشرًا إلى Security2 Architectural Protocol (للحصول على شرح مفصّل لهذه التقنية الاستغلالية المحددة، راجع المستودع التالي "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"). تُستشار هذه البروتوكول خدمة LoadImage لفرض سياسة Secure Boot، مما يعني أن الكتابة فوق gSecurity2 بمؤشر فارغ تعطّل فحوصات Secure Boot فعليًا أثناء التشغيل. والأهم أن هذا التجاوز شفاف بالنسبة لنظام التشغيل: فبمجرد الإقلاع، يظل Secure Boot يبدو ممكّنًا على مستوى نظام التشغيل رغم تعطيله بالكامل على مستوى البرامج الثابتة.

من الفروق المهمة أنه على المنصات القائمة على Insyde، يكون متغير IhisiParamBuffer عادةً مقفلًا للقراءة فقط، مما يمنع الاستغلال فعليًا على تلك الأنظمة دون ثغرة إضافية. ومن المفارقات أن هذا يعني أن المصنّع الذي قدّمت IBV الخاصة به نمط المتغير القابل للاستغلال في المقام الأول هو من بين الأقل تعرضًا، بينما تظل جميع المنصات الأخرى معرّضة للخطر. وفي الحالات التي يكون فيها المتغير مقفلًا، يمكن ربط تجاوز مثل BRLY-2023-005 للحصول على صلاحية الكتابة إلى المتغير قبل المضي في الاستغلال. أما على الأنظمة التي يكون فيها المتغير قابلًا للكتابة مباشرةً، فإن الهجوم مباشر وموثوق للغاية.