
يوضح CVE-2022-34302، وهو تجاوز لـ Secure Boot عبر محمّل الإقلاع الموقّع من New Horizon Datasys الذي ينفّذ محمّل PE/COFF المخصص المدمج فيه تطبيقات UEFI غير موقّعة.
محمّل الإقلاع Reboot Restore من New Horizon Datasys - أحضر تطبيق UEFI الضعيف الخاص بك (BYOVUA) - تجاوز Secure Boot عبر محمّل إقلاع موقّع يحتوي على محمّل PE/COFF مخصص مدمج يقوم بتحميل تطبيقات UEFI غير الموقّعة.
يوضّح هذا المستودع تقنية BYOVUA (أحضر تطبيق UEFI الضعيف الخاص بك) من خلال استغلال CVE-2022-34302، وهي ثغرة تجاوز Secure Boot في محمّل الإقلاع New Horizon Datasys.
على عكس الثغرات القائمة على UEFI Shell (CVE-2022-34301 وCVE-2022-34303)، لا يوفّر محمّل الإقلاع هذا واجهة UEFI Shell. بدلاً من ذلك، يطبّق shdloader.efi محمّل PE/COFF مخصصًا خاصًا به يقوم بتحميل ملف ثنائي من المرحلة الثانية (shdmgr.ef_) دون استخدام دالة LoadImage() الخاصة بالبرنامج الثابت ودون إجراء أي تحقق من التوقيع. يحتاج المهاجم فقط إلى استبدال shdmgr.ef_ بأي تطبيق UEFI متوافق لتحقيق تنفيذ كود عشوائي مع تمكين Secure Boot.
تُعدّ هذه أخطر الثغرات الثلاث المُفصح عنها في بحث "One Bootloader to Load Them All". وكما أشارت Eclypsium: فإن التجاوز مدمج، وصامت تمامًا، ولا يترك أي مؤشر مرئي على الشاشة - مما يجعله غير مرئي حتى على الأنظمة المزوّدة بشاشة، وغير قابل للاكتشاف على الأنظمة التي تعمل بدون شاشة مثل الخوادم أو المعدات الصناعية.
BYOVUA هو المكافئ لتقنية BYOVD (أحضر برنامج التشغيل الضعيف الخاص بك) المستخدمة على مستوى النواة، ولكن في سياق UEFI. فبدلاً من إحضار برنامج تشغيل نواة موقّع يحتوي على ثغرة، يُحضر المهاجم تطبيق UEFI موقّعًا يحتوي على وظائف قادرة على تقويض Secure Boot.
ولأن shdloader.efi موقّع بشهادة موثوقة من Microsoft، فإن Secure Boot يقبله دون سؤال، مما يجعله موثوقًا على أي نظام يتضمّن هذه الشهادة في قاعدة بيانات Secure Boot الخاصة به (db) - وهو عمليًا كل جهاز حاسوب يدعم UEFI تم شحنه خلال العقد الماضي. وبمجرد تشغيله، يمنح محمّل PE المخصص المدمج المهاجم القدرة على تحميل وتنفيذ كود عشوائي غير موقّع قبل تحميل نظام التشغيل، في بيئة لا توجد فيها ضوابط الأمان الحديثة (ASLR، DEP، حمايات النواة) ببساطة.
shdloader.efi هو محمّل إقلاع UEFI يُوزَّع كجزء من منتجات استعادة النظام والاسترداد من New Horizon Datasys (Reboot Restore Rx، RollBack Rx). ويتمثل دوره في سلسلة الإقلاع المشروعة في تحميل مكوّن إدارة ما قبل نظام التشغيل (shdmgr.ef_) الذي يتعامل مع عمليات اللقطات والاستعادة قبل بدء نظام التشغيل.
| الخاصية | القيمة |
|---|---|
| الملف | shdloader.efi = EFI/Boot/bootx64.efi |
| المورّد | New Horizon Datasys Inc |
| المنتج | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| التوقيع | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| الاكتشاف | Eclypsium (Mickey Shkatov، Jesse Michael) - أغسطس 2022 |
| العرض التقديمي | DEF CON 30 - "One Bootloader to Load Them All" |
| الإبطال | أُضيف إلى DBX عبر Microsoft KB5012170 (أغسطس 2022) |
الثغرة هي خلل في التصميم في بنية محمّل الإقلاع. فبدلاً من استخدام خدمات الإقلاع LoadImage() وStartImage() الخاصة بالبرنامج الثابت - التي تفرض التحقق من توقيع Secure Boot - يطبّق shdloader.efi محمّل PE/COFF مخصصًا خاصًا به يقرأ shdmgr.ef_ ويعيد تحديد موقعه وينفّذه مباشرة من بايتات القرص الخام، متجاوزًا بذلك فحوصات الأمان الخاصة بالبرنامج الثابت بالكامل.
المشكلة الجوهرية: ملف ثنائي موقّع موثوق من Secure Boot يحتوي على محمّل صور خاص به لا يتحقق من التوقيعات. يتحقق البرنامج الثابت من أن shdloader.efi موقّع، ولكن بمجرد تشغيله، يقوم بتحميل shdmgr.ef_ دون أي تحقق على الإطلاق. ويؤدي استبدال shdmgr.ef_ بتطبيق UEFI عشوائي إلى تشغيل ذلك التطبيق بوصول كامل إلى العتاد، بينما يُبلّغ Secure Boot عن أنه مُفعّل.
يختلف هذا اختلافًا جوهريًا عن CVE-2022-34301 وCVE-2022-34303، حيث يحتاج المهاجم إلى التفاعل مع UEFI Shell وإفساد gSecurity2 يدويًا لتعطيل التحقق. أما هنا، فالتجاوز تلقائي وصامت - لا تفاعل من المستخدم، ولا مخرجات مرئية، ولا موجّه أوامر.
يحتوي shdloader.efi الموقّع على تطبيق خاص به لمحمّل صور PE/COFF. فبدلاً من استدعاء خدمة الإقلاع LoadImage() الخاصة بالبرنامج الثابت، التي كانت ستستدعي بروتوكولات البنية الأمنية وتتحقق من توقيع الصورة مقابل قاعدة بيانات Secure Boot، يقوم محمّل الإقلاع بما يلي:
\EFI\Boot\shdmgr.ef_ باستخدام EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc ويطبّق إعادة تحديد الموقع الأساسيفي أي مرحلة من هذه العملية، لا يتحقق المحمّل من توقيع Authenticode للصورة، ولا يفحص قاعدة بيانات Secure Boot (db/dbx)، ولا يستدعي EFI_SECURITY2_ARCH_PROTOCOL. يتم تحميل الصورة بناءً فقط على صلاحيتها البنيوية لـ PE/COFF.```c
// Pseudocode of what shdloader.efi does internally
//
// NOTE: This is a simplified representation. The actual
// implementation was derived from reverse engineering.
EFI_STATUS LoadShdmgr(VOID) { // Step 1: Open the file File = OpenFile(L"\EFI\Boot\shdmgr.ef_");
// Step 2: Read raw bytes (no signature check)
ReadFile(File, &Buffer, &Size);
// Step 3: Parse PE/COFF headers
DosHeader = (EFI_IMAGE_DOS_HEADER *)Buffer;
PeHeader = (EFI_IMAGE_NT_HEADERS *)(Buffer + DosHeader->e_lfanew);
// Step 4: Allocate memory and copy sections
ImageBase = AllocatePages(...);
CopySections(ImageBase, Buffer, PeHeader);
// Step 5: Apply base relocations from .reloc
Delta = ImageBase - PeHeader->OptionalHeader.ImageBase;
ApplyRelocations(ImageBase, PeHeader, Delta);
// Step 6: Jump to entry point
// NO SIGNATURE VERIFICATION ANYWHERE
EntryPoint = ImageBase + PeHeader->OptionalHeader.AddressOfEntryPoint;
((EFI_IMAGE_ENTRY_POINT)EntryPoint)(ImageHandle, SystemTable);
}
---
<div id='LoadImageVsCustomLoader'/>
### ***LoadImage مقابل محمّل مخصص***