اكتشف الباحثون في شركة أمن البرامج الثابتة Binarly ستة عيوب جديدة في برنامج U-Boot، وهو البرنامج الصغير الذي يبدأ تشغيل أجهزة متنوعة مثل أجهزة التوجيه المنزلية، والكاميرات الذكية، ورقائق الإدارة داخل خوادم مركز البيانات.

يمكن لأربعة من الأخطاء أن تؤدي إلى تعطل الجهاز. يمكن للاثنين الآخرين السماح للمهاجم الذي يقوم بإدخال صورة ضارة أمام أداة تحميل التشغيل بتشغيل التعليمات البرمجية الخاصة به، قبل أن يؤكد الجهاز أن البرنامج أصلي.

هذا الجزء الأخير هو النقطة. يعمل محمل الإقلاع قبل نظام التشغيل، لذلك يمكن أن يؤدي الخلل هنا إلى تقويض كل ما يتم تحميله بعده. تم الوصول إلى جميع الأخطاء الستة بينما لا يزال U-Boot يقرأ صورة غير موثوق بها، قبل أن يتحقق من التوقيع.

ما وجده بيناريلي

يستطيع U-Boot تجميع النواة وشجرة الجهاز وقرص الذاكرة العشوائية ومكونات التمهيد الأخرى في حزمة واحدة، وهي FIT (شجرة الصور المسطحة)، ويتحقق من التوقيع الرقمي لتلك الحزمة قبل تسليم السيطرة.

ذهب بينارلي للبحث عن نقاط الضعف في هذا الشيك ووجد ستة. معظم التعليمات البرمجية الضعيفة موجودة في U-Boot منذ الإصدار v2013.07، كما يقول Binarly، عبر أكثر من 50 إصدارًا مستقرًا، كما أنها تعيش أيضًا في العديد من البرامج الثابتة الخاصة بالموردين المبنية على أعلى U-Boot.

يتم تعقب الأخطاء من خلال إرشادات Binarly من BRLY-2026-037 إلى BRLY-2026-042. لم يتم تعيين معرفات CVE حتى الآن. وهم ينقسمون إلى مجموعتين: مجموعتان يمكنها تشغيل التعليمات البرمجية، وأربعة يمكنها فقط التعطل.

الاثنان هما BRLY-2026-037 وBRLY-2026-038، وكلاهما يتتبعان قيمة واحدة لم يتم التحقق منها. يستدعي U-Boot fdt_get_name، وهو بحث في مكتبة تحليل شجرة الجهاز التي يستعيرها، وعلى صورة مشوهة، يُرجع هذا البحث مؤشرًا فارغًا وطولًا سالبًا. يستخدم U-Boot كليهما دون التحقق من أي منهما.

يتبع خطأ واحد المؤشر الفارغ في نسخة الذاكرة، والتي، على الأجهزة التي تم تعيين العنوان صفر فيها، تصبح تجاوز سعة المخزن المؤقت للمكدس. والآخر يغذي الطول السالب في حساب المؤشر الذي يسير للخلف حتى يقوم بالكتابة فوق عنوان الإرجاع المحفوظ. في تخطيط الذاكرة الصحيح، يمكن لأي منهما التحكم في التعليمات البرمجية التي يوفرها المهاجم.

الأربعة الآخرون يعطلون أداة تحميل التشغيل فقط. تتم قراءة BRLY-2026-039 وBRLY-2026-041 بعد نهاية الصورة من خلال الوثوق بالحجم أو الإزاحة التي يتحكم فيها المهاجم. يقوم BRLY-2026-040 بإلغاء الإشارة إلى المؤشر الفارغ الذي يقوم تنسيق الصورة الأقدم بإرجاعه دون تحديد. BRLY-2026-042 يستنفد المكدس، ويتم إطلاقه بواسطة صورة متداخلة بعمق تدفع خطوة التحقق المبكرة إلى الاتصال بنفسها حتى نفادها.

قامت Binarly بنشر صورة إثبات المفهوم وخطوات إعادة الإنتاج لكل عيب وإظهارها مقابل إصدارات U-Boot القياسية. ولم يتم الإبلاغ عن أي استغلال في الهجمات الحقيقية.

من بين الأخطاء الستة، هناك خللان يتعلقان بتلف الذاكرة هما اللذان يجب تحديدهما حسب الأولوية: يمكن أن يؤدي التعطل إلى جعل الجهاز غير متصل بالإنترنت، ولكن تنفيذ التعليمات البرمجية عند التمهيد يمكن أن يؤدي إلى تقويض سلسلة الثقة بأكملها.

ما مدى سوء الأمر

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

المشكلة التي يواجهها المهاجم هي التسليم: هذه الأخطاء لا تلدغ إلا بمجرد وصول صورة ضارة إلى مسار التمهيد، والذي يتطلب عادةً وصولاً فعليًا أو موطئ قدم مميز. إن موطئ القدم هذا ليس دائما محليا.

في عمل سابق على وحدات التحكم في إدارة خادم Supermicro، أظهر نفس الباحث في Binarly أن المهاجم الذي لديه إمكانية الوصول عن بعد إلى واجهة الإدارة يمكنه إساءة استخدام عملية التحديث الخاصة بالجهاز لإصدار صورة ضارة، دون لمس الأجهزة.

ما يجب القيام به

لا يوجد إصدار مستقر مع الإصلاح حتى الآن، لذلك يجب على البائعين ومشرفي المنتجات المستندة إلى U-Boot ألا ينتظروا: اسحب الإصلاحات الأولية الآن، باتباع روابط الالتزام في كل نصيحة من Binarly، وتتبعها بواسطة المعرف الاستشاري، نظرًا لعدم وجود CVEs.

قامت U-Boot بدمج التصحيحات الستة في يونيو، ولكن إصدار يوليو (v2026.07) كان قد تم تجميده بالفعل في أبريل، لذلك تم شحنه بدونها؛ الإصدار التالي، v2026.10، لن يصدر حتى أكتوبر.

يقوم أي شخص آخر بتشغيل جهاز تم تصميمه بواسطة شخص آخر على U-Boot. بالنسبة لهم، يجب أن يصل الإصلاح كتحديث للبرنامج الثابت من بائع المنتج. هذا هو ما يجب مراقبته.

لقد فشل هذا الفحص الدقيق من قبل. تم الوصول إلى نفس منطق التوقيع قبل أشهر بواسطة CVE-2026-33243، والذي قام U-Boot بتصحيحه في أبريل؛ تم أيضًا إصابة أداة تحميل التشغيل ذات الصلة، والتي تستخدم نفس أدوات الصور.

في هذا الخطأ، كانت الخاصية تعني فقط سرد ما لم يتم التوقيع على أغلفة التوقيع في حد ذاته، لذلك يمكن تبديل الصورة التي تم التلاعب بها في أجزاء لم يتم التحقق منها مطلقًا. المساعد وراء أسوأ خللين هنا، fdt_get_name، يأتي من libfdt، مكتبة U-Boot لشجرة الأجهزة المسطحة التي تشاركها مع Linux kernel، وbarebox، وغيرها. يمكن أن يظهر نفس خطأ الإرجاع غير المحدد في أي مكان يتم فيه استخدام هذا الرمز.

كان LogoFAIL، الذي غطته THN في عام 2023، عبارة عن مجموعة من الأخطاء في تحليل الصور في البرامج الثابتة للكمبيوتر الشخصي والتي سمحت بتشغيل تعليمات برمجية للمهاجم أثناء التمهيد، قبل أن يتمكن Secure Boot من التحقق من أي شيء، عبر كل علامة تجارية رئيسية لأجهزة الكمبيوتر تقريبًا. التوقيع يحظى بكل الاهتمام. تستمر الحشرات في الهبوط في السباكة التي تمر أمامها.

وكما أظهر BootHole في عام 2020، عندما أدى أحد العيوب في أداة تحميل التشغيل إلى تعطيل Secure Boot عبر النظام البيئي، فإن كتابة التصحيح هي الجزء السهل. الجزء البطيء هو توصيله إلى ملايين الأجهزة التي تشغل نسخة U-Boot الخاصة بشخص آخر.

شاركها.
اترك تعليقاً