في عالم التكنولوجيا المتطور، تم اكتشاف ستة عيوب جديدة في U-Boot، مما يثير القلق حول أمان الأجهزة المتنوعة.
ستة عيوب جديدة في U-Boot قد تسمح للصور الضارة بتعطيل الأجهزة أو تشغيل التعليمات البرمجية عند بدء التشغيل
اكتشف الباحثون في شركة Binarly للأمن البرمجي ستة عيوب جديدة في U-Boot، البرنامج الصغير الذي يبدأ تشغيل الأجهزة مثل أجهزة التوجيه المنزلية والكاميرات الذكية ورقائق الإدارة داخل خوادم مراكز البيانات.
يمكن لأربعة من هذه العيوب تعطيل الجهاز. بينما يمكن للاثنين الآخرين أن يسمحا لمهاجم يقوم بإدخال صورة ضارة أمام محمل الإقلاع بتشغيل التعليمات البرمجية الخاصة به، قبل أن تؤكد الجهاز أن البرنامج موثوق.
هذه النقطة هي الأهم. يعمل محمل الإقلاع قبل نظام التشغيل، لذا فإن وجود عيب هنا يمكن أن يقوض كل ما يتم تحميله بعده. جميع العيوب الستة يمكن الوصول إليها أثناء قراءة U-Boot لصورة غير موثوقة، قبل أن يتحقق من التوقيع.
ما وجده Binarly
يمكن لـ U-Boot تجميع نواة ونموذج جهاز وramdisk ومكونات بدء تشغيل أخرى في حزمة واحدة، وهي FIT (شجرة الصورة المسطحة)، ويتحقق من التوقيع الرقمي لتلك الحزمة قبل تسليم السيطرة.
بحثت Binarly عن نقاط الضعف في ذلك التحقق ووجدت ستة. معظم الشيفرات الضعيفة كانت موجودة في 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 بتصحيحها في أبريل؛ تم ضرب محمل الإقلاع barebox المرتبط، الذي يستخدم نفس أدوات الصورة، أيضًا.
في تلك العيب، كانت خاصية تهدف فقط إلى سرد ما يغطيه التوقيع غير موقعة بنفسها، لذا يمكن لصورة تم العبث بها تبديل أجزاء لم يتم التحقق منها. المساعد وراء أسوأ عيبين هنا، fdt_get_name، يأتي من libfdt، مكتبة شجرة الجهاز المسطحة التي يشاركها U-Boot مع نواة لينكس وbarebox وآخرين. يمكن أن تظهر نفس خطأ عدم التحقق في أي مكان تستخدم فيه الشيفرة.
LogoFAIL، الذي غطته THN في 2023، كان مجموعة من عيوب تحليل الصور في البرنامج الثابت للكمبيوتر التي سمحت بتشغيل تعليمات برمجية المهاجم أثناء بدء التشغيل، قبل أن يتمكن Secure Boot من التحقق من أي شيء، عبر كل علامة تجارية رئيسية للكمبيوتر. يحصل التوقيع على كل الاهتمام؛ تستمر العيوب في الهبوط في الأنابيب التي تعمل قبل ذلك.
وكما أظهر BootHole في 2020، عندما كسر عيب واحد في محمل الإقلاع Secure Boot عبر النظام البيئي، فإن كتابة التصحيح هي الجزء السهل. الجزء البطيء هو الحصول عليه على الملايين من الأجهزة التي تعمل بنسخة شخص آخر من U-Boot.
يجب على الشركات المصنعة والمستخدمين متابعة التحديثات لضمان حماية أجهزتهم من هذه الثغرات.
