يمكن لهذا أن يحل محل ملف تنفيذي شرعي، أو يختطف 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)، مما قد يمنع تنفيذ الملفات الثنائية. ومع ذلك، إذا تم اختراق نظام التشغيل أيضًا، فقد يتم التراجع عن هذا الإجراء العلاجي.

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

## الكشف

بافتراض إنشاء روتكيت على مستوى النواة مثالي لاستغلال هذه الثغرة، لا يمكن الوثوق بالبيانات المتعلقة بالنظام الجاري.

تشمل طرق الكشف ما يلي:

- التحقق من وجود الملفات الثنائية المعنية
- التحقق من التوقيعات/سلامة الملفات المعروفة، مثل [rkhunter](https://rkhunter.sourceforge.net/)
- تحليل السلوك، خاصة في البيئات المتصلة بالشبكة

على أقل تقدير، يجب أن تكون الملفات الثنائية EFI الموقعة التي سيتم إقلاعها بواسطة البرامج الثابتة للنظام ونواة IGEL موجودة على النظام المخترق، ولكن نظرًا [لمستوى](https://en.wikipedia.org/wiki/Protection_ring) التنفيذ الذي سيعمل عليه الكود الضار، يمكن أن يخفي [الروتكيت](https://en.wikipedia.org/wiki/Rootkit) نفسه أثناء التشغيل.

تعتمد مؤشرات الاختراق الأخرى على إجراءات البرامج الضارة التي استغلت هذه الثغرة. على سبيل المثال، قد تم استبدال النواة المُقلعة، أو تعديل الملفات على نظام الجذر، أو تشغيل برامج غير متوقعة.

## التخفيف

> [!IMPORTANT]
> أصدرت مايكروسوفت [DBX موقعة](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed) تلغي توقيعات الشيم (shims) المعنية بتاريخ 20 أكتوبر 2025، بعد اتفاق مع IGEL.
>
> بالنسبة لأنظمة ويندوز، يرجى الاطلاع على
> [دليل تحديث MSRC](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> لتحديث الأنظمة القائمة على لينكس باستخدام [fwupd](https://fwupd.org/)، قم بتحديث
> [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware)
> إلى الإصدار `20250902` فصاعدًا.
>
> لمزيد من المعلومات، انظر [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272).

لمنع اختراق سلسلة الإقلاع، يجب إبطال/عدم الثقة بالشهادة المستخدمة لتوقيع صورة GRUB/النواة الضعيفة، أو يجب إضافة تجزئات SHA-256 للنواة (أو الشيم) المتأثرة إلى قائمة المنع DBX أو MOKX.
انظر [التوثيق من مديرية الأمن السيبراني التابعة لوكالة الأمن القومي](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md) لمزيد من المعلومات.

بدلاً من ذلك، لمنع تنفيذ الشيم الأولي، يمكن عدم الثقة بالمرجع المصدق الثالث UEFI من مايكروسوفت (Microsoft 3rd Party UEFI CA)، لكن هذا قد يسبب تعطيلًا غير مقصود لتطبيقات شرعية أخرى.
تحتوي بعض الأجهزة على هذا الخيار في إعدادات البرامج الثابتة.

يحذر [صفحة ArchWiki لـ sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) مما يلي:

> [!WARNING]
> بعض البرامج الثابتة موقعة ومتحقق منها باستخدام مفاتيح مايكروسوفت عند تمكين التمهيد الآمن. قد يؤدي عدم التحقق من الأجهزة إلى تعطيلها (brick).

هذا هو [الإعداد الافتراضي لأجهزة Secured-core PCs](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):

> الحالة الافتراضية للتمهيد الآمن لديها دائرة ثقة واسعة، مما قد يؤدي إلى ثقة العملاء بمكونات إقلاع قد لا يحتاجونها. نظرًا لأن شهادة المرجع المصّدق الثالث UEFI من مايكروسوفت توقع على مُحملات الإقلاع لجميع توزيعات لينكس، فإن الثقة بتوقيع المرجع المصّدق الثالث UEFI من مايكروسوفت في قاعدة بيانات UEFI تزيد من سطح الهجوم للأنظمة. العميل الذي كان ينوي فقط الثقة والإقلاع بتوزيعة لينكس واحدة سيثق بجميع التوزيعات - أكثر من التكوين المطلوب. أي ثغرة في أي من مُحملات الإقلاع تعرض النظام للخطر وتضع العميل في خطر استغلال مُحمل إقلاع لم ينوي استخدامه أبدًا، كما رأينا في الثغرات الأخيرة، على سبيل المثال [مع مُحمل الإقلاع GRUB](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) أو [روتكيت على مستوى البرامج الثابتة](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit) الذي يؤثر على مكونات الإقلاع.
> [أجهزة Secured-core PCs](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11) تتطلب تمكين Secure Boot وتكوينه لعدم الثقة بتوقيع المرجع المصّدق الثالث UEFI من مايكروسوفت، بشكل افتراضي، لتزويد العملاء بأكثر تكوين آمن ممكن لأجهزتهم.

### الإقلاع المُقاس (Measured Boot)

إذا تم إقلاع النظام باستخدام شيم IGEL، فإن [قياسات PCR الخاصة بـ TPM](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) ستتغير.

يستخدم ويندوز [Measured Boot](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot) بشكل افتراضي مع BitLocker، مما يجعل مفاتيح التشفير غير قابلة للوصول إذا لم يتم إقلاع النظام بالملفات الثنائية المتوقعة.

على الأنظمة القائمة على لينكس، يمكن استخدام [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) لتسجيل مفتاح LUKS في TPM وربطه بـ PCRs مختلفة (PCR 7 بشكل افتراضي).

يحمي الإقلاع المُقاس نظام التشغيل الشرعي من التعديل، عن طريق إطلاق مفتاح التشفير فقط في بيئة موثوقة. ومع ذلك، فإنه لا يمنع إقلاع نظام تشغيل غير مصرح به؛ فهذه مسؤولية التمهيد الآمن (Secure Boot).

لذلك، قد يظل المستخدم في خطر، حتى لو كان نظام تشغيله يستخدم الإقلاع المُقاس. على سبيل المثال:

- إقلاع شيم IGEL ونظام تشغيل ضار، مع اجتياز Secure Boot
- تقليد مظهر وسلوك نظام التشغيل الحقيقي
- إدخال المستخدم لبيانات الاعتماد التي يتم إرسالها إلى المهاجم
- اختياريًا، إعادة الإقلاع إلى نظام التشغيل الشرعي

بينما لا يمكن تعديل نظام التشغيل الشرعي باستخدام الإقلاع المُقاس، لأن مفتاح التشفير مرتبط بقياسات PCR الخاصة بـ TPM[^1]، لا يزال بإمكان النظام إقلاع برامج ضارة.

[^1]: مفاتيح استعادة BitLocker غير مرتبطة بـ TPM.

### صورة النواة الموحدة (Unified Kernel Image)

يمكن استخدام [صورة نواة موحدة](https://uapi-group.org/specifications/specs/unified_kernel_image/) لتجميع جميع موارد الإقلاع (أي النواة، القرص الرامي الأولي، سطر أوامر النواة، إلخ.) في ملف PE UEFI واحد.
يمكن توقيع هذه الصور مثل أي ملف EFI قابل للتنفيذ.
لتحسين أمان الإقلاع وتقليل سطح الهجوم لسلسلة الإقلاع، قم بإنشاء صورة نواة موحدة وتوقيعها بمفاتيح من إنشاء المستخدم، مع عدم الثقة بأي مفاتيح من البائع/OEM.

## الملفات الثنائية

الملفات الثنائية المعنية هي أدناه:

### الوصف

بترتيب التنفيذ:

- `boot*.efi` -> شيم موقعة من مايكروسوفت
- `igel*.efi` -> GRUB موقعة من IGEL
- `bzImage`   -> صورة لينكس (initramfs مدمجة)، موقعة من IGEL

يمكن العثور على الشهادة للموضوع `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE` في [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der).

بصمة SHA-256 لهذه الشهادة هي
`5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`.

يمكن التحقق من توقيعات هذه الملفات الثنائية باستخدام `sbverify` (من [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)):```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
  sbverify --cert igel-efi-pub-key.pem "${image}"
done

تم إبطال تجزئات [`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461)
و [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427)
عبر DBX.

## إثبات المفهوم

يتم توفير نص برمجي شل كإثبات للمفهوم لتنزيل ISO تثبيت IGEL OS، واستخراج وإنشاء صورة قرص قابلة للإقلاع، مع نظام ملفات جذر SquashFS معدل.

بدلاً من ذلك، بدلاً من صورة قرص، يمكن إعادة تعبئة ISO مع قسم نظام EFI ملحق بالصورة. كما يمكن استخدام MBR هجين للاحتفاظ بدعم أنظمة BIOS القديمة، لكن هذا خارج نطاق هذا المشروع. يحتوي ISO التثبيت على محمل إقلاع ISOLINUX للأنظمة القديمة، والذي يقوم بتحميل متسلسل لـ `core.img` الخاص بـ GRUB.

### التراكبات

يتم توفير أدلة تراكب مثال، لإظهار إقلاع بيئة Arch Linux المباشرة عبر HTTP.

سينفذ النص البرمجي `init` تحميل النواة المحددة في معلمات سطر أوامر النواة باستخدام `kexec`، ثم يعيد التشغيل. لا يحتاج النواة البديلة إلى أن تكون موقعة، إذا تم تمرير `--kexec-syscall` بدلاً من `--kexec-file-syscall`.

يتم تخزين ملف تكوين GRUB على قسم نظام EFI، والذي يمكن تعديله بسهولة. يمكن وضع ملفات أخرى على ESP، مثل النواة أو initramfs أو صور SquashFS، ليتم الإقلاع منها من نظام الملفات الجذر الأول باستخدام `kexec`. يتيح ذلك التحميل المتسلسل لنظام آخر محلياً، والذي يمكن تحديثه كنظام عادي، دون إعادة بناء ISO في كل مرة.

بدلاً من ذلك، يمكن تنزيل الملفات المطلوبة عبر HTTP باستخدام `curl`، ثم إقلاعها، للحصول على صورة قرص أصغر.

هذا مثال بريء لكيفية استغلال الثغرة، ولكن يمكن تعديل النص البرمجي `init` أو نواة `kexec` لإظهار سلوك ضار.

### التبعيات

يتطلب النص البرمجي الحزم التالية:

- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`، وكل شيء آخر)
- [`dosfstools`](https://github.com/dosfstools/dosfstools) (`mkfs.fat`)
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn) (`osirrox`، `xorriso`)
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools) (`mksquashfs`، `unsquashfs`)
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux) (`fdisk`، `losetup`)
- [`wget`](https://www.gnu.org/software/wget/wget.html)

يجب أن تكون هذه الحزم متاحة لأي توزيعة من مستودعات الحزم الرسمية.

يمكن تثبيت `igelfs-cli` في بيئة افتراضية من
[PyPI](https://pypi.org/project/igelfs/):```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs

### مثال

قم ببناء صورة قرص بحجم 500 ميجابايت، مع نسخ محتويات `esp` و `root` إلى EFI System Partition و SquashFS على التوالي:```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"

ملاحظة: نظرًا لطريقة البحث عن السلاسل الفرعية في `parse_cmdline` التابع لـ initramfs الخاص بـ IGEL، فإن تحديد `init` في أي مكان من سطر أوامر kernel سيتم تفسيره بواسطة initramfs الأول، لذلك لا يمكن تمرير `init` إلى kernel الخاص بـ `kexec` عبر معاملات kernel الأولى.

### SSL

إذا كان SSL مطلوبًا، مثل HTTPS، قم بإضافة `/etc/ssl/certs/ca-certificates.crt` إلى صورة SquashFS.

### المتطلبات

يجب أن يكون ISO هو القسم الأول، مما يجعل قسم النظام EFI (ESP) بشكل غير تقليدي القسم رقم 2. وذلك بسبب كيفية قيام سكريبت `init` الخاص بـ initramfs بالبحث في الأجهزة.
وبالمثل، عند تثبيته، يقوم IGEL OS بإنشاء قسمين ESP في القسمين رقم 2 و 3.

يتطلب GRUB وجود `/boot/igel-ud-converter` على نفس نظام الملفات مثل `/boot/grub/igel.conf`:```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf