Это может заменить легитимный исполняемый файл, перехватить PID 1 или автоматически запускать себя при загрузке, легко получая root-доступ.

`/proc/cmdline` может быть [перехвачен](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline) с помощью bind mount, чтобы скрыть любые изменения.

Смотрите [документацию Linux](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) для получения дополнительной информации.

### Persistence

Воздействие будет постоянным, пока необходимые EFI-бинарники и ядро присутствуют и настроены для загрузки системной прошивкой.

Обновления операционной системы могут вызвать изменения в порядке загрузки или в базе данных запрещенных подписей Secure Boot (DBX), что может помешать выполнению бинарников. Однако, если операционная система также скомпрометирована, это remedial действие может быть отменено.

Кроме того, так как порядок загрузки EFI настраивается операционной системой через изменение EFI-переменных, привилегированное вредоносное ПО может получить постоянство или дополнительно повысить привилегии, установив необходимые загрузочные файлы и настроив соответствующий порядок загрузки.

## Detection

Предполагая, что был создан идеальный руткит на уровне ядра для эксплуатации этой уязвимости, данные о работающей системе нельзя доверять.

Методы обнаружения включают:

- Проверка наличия задействованных бинарников
- Проверка подписей/целостности известных файлов, например, [rkhunter](https://rkhunter.sourceforge.net/)
- Поведенческий анализ, особенно в сетевых средах

Как минимум, подписанные EFI-бинарники, загружаемые системной прошивкой, и ядро IGEL должны присутствовать на скомпрометированной системе, но, из-за [уровня](https://en.wikipedia.org/wiki/Protection_ring), на котором выполняется вредоносный код, [руткит](https://en.wikipedia.org/wiki/Rootkit) может скрывать себя во время выполнения.

Другие индикаторы компрометации зависят от действий вредоносного ПО, которое использовало эту уязвимость. Например, загруженное ядро может быть заменено, файлы в корневой файловой системе изменены, или могут работать неожиданные программы.

## Mitigation

> [!IMPORTANT]
> Microsoft выпустил [подписанную DBX](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed), отзывающую подписи соответствующих shim'ов 20 октября 2025 года после соглашения с IGEL.
>
> Для систем Windows, пожалуйста, смотрите [руководство по обновлению MSRC](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> Чтобы обновить системы на базе Linux с помощью [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 затронутых ядер (или shim'ов) должны быть добавлены в список запрета DBX или MOKX.
Смотрите [документацию от Директората кибербезопасности АНБ](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md) для получения дополнительной информации.

В качестве альтернативы, чтобы предотвратить выполнение начального shim'а, можно отозвать доверие к Microsoft 3rd Party UEFI CA, но это может вызвать непреднамеренные сбои в других легитимных приложениях.
На некоторых устройствах это есть как опция в настройках прошивки.

Страница [ArchWiki для sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) предупреждает следующее:

> [!WARNING]
> Некоторые прошивки подписаны и проверяются ключами Microsoft, когда Secure Boot включен. Непроверка устройств может заблокировать их (brick).

Это [по умолчанию для Secured-core ПК](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):

> По умолчанию состояние Secure Boot имеет широкий круг доверия, что может привести к тому, что клиенты будут доверять компонентам загрузки, которые им не нужны. Поскольку сертификат Microsoft 3rd Party UEFI CA подписывает загрузчики для всех дистрибутивов Linux, доверие к подписи Microsoft 3rd Party UEFI CA в базе UEFI увеличивает поверхность атаки систем. Клиент, который намеревался доверять и загружать только один дистрибутив Linux, будет доверять всем дистрибутивам — больше, чем желаемая конфигурация. Уязвимость в любом из загрузчиков подвергает систему риску и ставит клиента под угрозу эксплуатации загрузчика, который он никогда не намеревался использовать, как видно в недавних уязвимостях, например [с загрузчиком GRUB](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) или [руткитом на уровне прошивки](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit), влияющим на компоненты загрузки. [Secured-core ПК](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11) требуют, чтобы Secure Boot был включен и настроен на недоверие к подписи Microsoft 3rd Party UEFI CA по умолчанию, чтобы предоставить клиентам максимально безопасную конфигурацию их ПК.

### Measured Boot

Если система загружается с IGEL shim, [измерения TPM PCR](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) изменятся.

Windows использует [Measured Boot](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot) по умолчанию с BitLocker, делая ключи шифрования недоступными, если система не загружается с ожидаемыми бинарниками.

В системах на базе Linux [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) можно использовать для регистрации ключа LUKS в TPM и привязки к различным PCR (по умолчанию PCR 7).

Measured Boot защищает легитимную ОС от модификации, высвобождая ключ шифрования только в доверенной среде. Однако он не предотвращает загрузку неавторизованной ОС; это ответственность Secure Boot.

Следовательно, пользователь все еще может быть в опасности, даже если его ОС использует Measured Boot. Например:

- Загрузить IGEL shim и вредоносную ОС, пройдя Secure Boot
- Эмулировать внешний вид и поведение подлинной ОС
- Пользователь вводит учетные данные, которые отправляются атакующему
- Опционально, перезагрузиться в легитимную ОС

Хотя легитимная ОС не может быть изменена с помощью Measured Boot, поскольку ключ шифрования привязан к измерениям TPM PCR[^1], система все еще может загружать вредоносное ПО.

[^1]: Ключи восстановления BitLocker не привязаны к TPM.

### Unified Kernel Image

Образ [унифицированного ядра](https://uapi-group.org/specifications/specs/unified_kernel_image/) можно использовать для объединения всех загрузочных ресурсов (т.е. ядра, начального ramdisk, командной строки ядра и т.д.) в один файл UEFI PE. Эти образы могут быть подписаны как любые другие исполняемые файлы EFI. Для повышения безопасности загрузки и минимизации поверхности атаки цепочки загрузки создайте унифицированный образ ядра и подпишите его сгенерированными пользователем ключами, отозвав доверие к любым ключам вендора/OEM.

## Binaries

### Description

В порядке выполнения:

- `boot*.efi` -> shim, подписанный Microsoft
- `igel*.efi` -> GRUB, подписанный IGEL
- `bzImage`   -> образ Linux (встроенный 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.

## Доказательство концепции

Предоставляется shell-скрипт доказательства концепции для загрузки установочного ISO IGEL OS, извлечения и создания загрузочного образа диска с модифицированной корневой файловой системой SquashFS.

В качестве альтернативы, вместо образа диска, ISO можно перепаковать с разделом EFI System, добавленным к образу. Также можно использовать гибридную MBR для сохранения поддержки устаревших систем BIOS, но это выходит за рамки данного проекта. Установочный ISO содержит загрузчик ISOLINUX для устаревших систем, который цепляет GRUB `core.img`.

### Наложения

Предоставлены примеры каталогов наложений для демонстрации загрузки живого окружения Arch Linux по HTTP.

Скрипт `init` загрузит указанное ядро через параметры командной строки ядра с помощью `kexec`, а затем перезагрузится. Заменяющее ядро не нужно подписывать, если передаётся `--kexec-syscall` вместо `--kexec-file-syscall`.

Файл конфигурации GRUB хранится на разделе EFI System Partition, который можно легко изменить. Другие файлы можно поместить на 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` _где-либо_ в командной строке ядра будет интерпретировано первым initramfs, поэтому `init` не может быть передан ядру `kexec` через параметры первого ядра.

### SSL

Если требуется SSL, например, для HTTPS, добавьте `/etc/ssl/certs/ca-certificates.crt` в образ SquashFS.

### Требования

ISO-образ должен быть первым разделом, что делает системный раздел EFI (ESP) нетрадиционно вторым разделом. Это связано с тем, как скрипт `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