Microsoft تلغي 11 وحدة Secure Boot بعد كشف ESET خطر التجاوز
أفادت Ars Technica بأن ESET عثرت على 11 صورة UEFI shim قديمة ظلت Microsoft تثق بها رغم عيوب معروفة. وألغت Microsoft الثقة بهذه الوحدات في تحديثات يونيو، لكنها لم توضح كيف استمر الخلل لسنوات.
ظلت 11 صورة قديمة من UEFI shim موثوقة حتى إصدار تصحيحات Microsoft في يونيو، بعدما خلص باحثو ESET إلى أنها قد تساعد في تجاوز Secure Boot على أجهزة Windows وLinux، كما كتبت Ars Technica. وأشارت المنصة إلى أن الصور المتأثرة شملت واحدة على الأقل من عام 2013، وأنها بقيت موقعة حتى بعد تحديد عيوب معروفة فيها.
يهدف Secure Boot إلى منع البرمجيات الثابتة الخبيثة من التحميل قبل بدء نظام التشغيل. وشرحت Ars Technica أن وحدات shim القديمة قد تتيح لمهاجم كسر سلسلة الإقلاع الموقعة وتثبيت برمجيات ثابتة تعمل مبكرا في عملية التشغيل، بما في ذلك برمجيات خبيثة يمكن أن تبقى حتى بعد إعادة تثبيت نظام التشغيل أو استبدال القرص الصلب.
وطُرح Secure Boot في عام 2012 لتقليل مخاطر bootkits، أي البرمجيات الثابتة الخبيثة التي تُحمَّل قبل بدء نظام التشغيل. وأشارت Ars Technica إلى أمثلة سابقة على ذلك من أعوام 2018 و2020 و2022 و2023، مضيفة أن الوصول الفيزيائي إلى الجهاز يُعد أحد نماذج التهديد التي يفترض أن يعالجها Secure Boot.
ESET Found 11 Trusted UEFI Shim Images
كتب باحث ESET Martin Smolár أن الخطر نجم عن ملفات shim قديمة ما زالت موثوقة، لا عن ثغرة جديدة. وتطلّبت هذه الطريقة نسخة من shim لم يُلغَ بعد، مع فهم أساسي لكيفية عمل UEFI shims، استنادا إلى منشور البحث الذي استشهدت به Ars Technica.
وضمت قائمة CERT وحدات shim استخدمتها توزيعات Linux مثل Red Hat وOpenSuse وOracle، إلى جانب برمجيات من أطراف ثالثة. وقد بُني بعض هذه الملفات قبل وجود وسائل حماية مثل SBAT وقوائم MOK للمنع، بينما راكم بعضها الآخر أخطاء في شفرته الخاصة أو في ملفات المرحلة الثانية التي يصرح لها.
The June Patch Revoked The Defective Shims
ألغت Microsoft أخيرا الوحدات الـ11 من shim في إصدارها المعتاد لتصحيحات يونيو، بعدما أحالت ESET الأمر إلى كل من CERT وMicrosoft، كما كتبت Ars Technica. وأضافت المطبوعة أن هذا القصور استمر لأكثر من عقد في بعض الحالات.
وتتسم عملية الإلغاء بالتعقيد لأن Secure Boot يستخدم عدة قواعد بيانات للثقة وآليات للتحكم في الإصدارات. وحددت Ars Technica قاعدة بيانات db للشهادات وتجزئات التوقيع المسموح بها، وقاعدة بيانات dbx للعناصر الملغاة، وأنظمة قائمة على الإصدارات تشمل Secure Boot Advanced Targeting وSecure Boot Security Version Number.
وتشير السجلات التي استندت إليها Ars Technica إلى أن قاعدة بيانات dbx لا تتسع إلا لـ 32kb، ما يجعل إدراج كل مكون Linux يُنفذ أثناء الإقلاع أمرا غير عملي. ودفع هذا القيد Microsoft إلى تبني آليات إلغاء قائمة على الإصدارات لتطبيقات UEFI المعرضة للخطر.
وكتب Smolár أن SBAT وSecure Boot SVN من Microsoft يلغيان الإصدارات بدلا من الملفات الثنائية الفردية. ويحمل كل مكون من مكونات تحميل UEFI بيانات وصفية موقعة تتضمن اسم المكون ورقم الجيل، ويتحقق shim من هذه البيانات في مقابل سياسة الحد الأدنى للإصدار قبل أن يحمّل نفسه أو ملفات ثنائية أخرى.
Windows And Linux Users Get Different Checks
وخلصت Ars Technica إلى أن وحدات shim الضعيفة يمكن استخدامها ضد أجهزة Windows وLinux، رغم أن أجهزة Windows 11 Secured-core على الأرجح غير معرضة في وضعها الافتراضي. ويؤكد السرد نفسه أن مستخدمي Windows الذين ثبّتوا دفعة تحديثات Microsoft لشهر يونيو لم يعودوا عرضة للخطر.
ونُصح مستخدمو Linux بفحص Linux Vendor Firmware Service أو مراجعة الموزع الخاص بهم. كما أشارت Ars Technica إلى أداة uefi-dbx-audit باعتبارها وسيلة للتحقق من حالة الإلغاء.
وقال الباحث في أمن البرمجيات الثابتة HD Moore لـ Ars Technica إن هذه النتيجة توبخ نموذج Secure Boot، مستندا إلى كون Microsoft جذر الثقة الفعلي لمنصة UEFI وإلى عدد المكونات الموقعة التي لا تزال قادرة على تشغيل شيفرة أخرى. ولا يوضح السرد العلني كيف أو لماذا ظلت وحدات shim المعيبة الإحدى عشرة موثوقة قبل إلغاء يونيو.
