Исследователи ESET обнаружили 11 старых UEFI-загрузчиков shim версии 0.9 и ниже, подписанных сертификатом Microsoft Corporation UEFI CA 2011. Они годами оставались доверенными и позволяли обходить UEFI Secure Boot на любой машине, где этот сертификат прописан в базе разрешённых подписей – независимо от установленной операционной системы.
Ключевая особенность случая: атакующему не нужен новый эксплойт. Достаточно копии старого, всё ещё доверенного файла и понимания того, как устроен shim. Microsoft отозвала уязвимые двоичные файлы 9 июня 2026 года во «Вторник Патчей», а технические подробности ESET раскрыла только 14 июля – месяц спустя, когда защита уже разошлась по системам.
Уязвимым загрузчикам присвоено два идентификатора: CVE-2026-8863 (набор затронутых shim) и CVE-2026-10797 (обход механизма отзыва в shim версии 0.9 и ниже). Работу координировал центр CERT/CC, случай отслеживается как VU#616257. Технический разбор опубликован в блоге ESET, автор исследования – Мартин Смолар.
Что такое shim и почему он важен
Secure Boot проверяет каждый загрузочный файл по двум базам в прошивке: db – разрешённые сертификаты и хеши, dbx – запрещённые. Файл должен быть подтверждён базой db и отсутствовать в dbx, иначе загрузка прерывается.
Прошивка сверяет каждый загрузочный файл с базами db и dbx. Источник: ESET
Для Linux прямая схема не работает: у каждого дистрибутива свой загрузчик со своим хешем, и отправлять каждую сборку на подпись в Microsoft нереально. Решением стал shim – минимальный загрузчик первой ступени, который Microsoft проверяет и подписывает один раз.
Дальше цепочка выстраивается так:
- прошивка проверяет подпись shim по сертификату Microsoft из базы db;
- shim проверяет загрузчик второй ступени (обычно GRUB 2) по вшитому в него сертификату разработчика дистрибутива;
- GRUB 2 проверяет ядро Linux тем же сертификатом и передаёт ему управление.
Каждое звено цепочки криптографически подтверждено предыдущим. Источник: ESET
Помимо сертификата разработчика, в shim часто встроен собственный сертификат конкретной сборки – им подписаны вспомогательные утилиты вроде MokManager.
Два механизма расширяют эту схему:
- MOK (Machine Owner Key) – ключи владельца компьютера. Список разрешённых хранится в переменной NVRAM MokList, список отозванных – в MokListX. Изменить обе переменные можно только на этапе загрузки, что требует физического доступа.
- SBAT (Secure Boot Advanced Targeting) – отзыв не по хешу отдельного файла, а по номеру поколения компонента. Каждый файл несёт метаданные в секции .sbat, а переменная SbatLevel задаёт минимально допустимое поколение. Политику проверяет сам shim, а не прошивка, поэтому обновления доходят быстрее, чем через dbx.
Ключ владельца компьютера расширяет цепочку доверия shim. Источник: ESET
Файл SbatLevel_Variable.txt в репозитории shim – единый источник отзывов SBAT. Источник: ESET
Отзыв по хешам появился первым, но плохо масштабируется. При устранении BootHole (CVE-2020-10713) в dbx добавили три сертификата и 150 хешей – около 10 КБ из типичных 32 КБ, доступных для списка отзыва на платформе. Именно нехватка места и подтолкнула к появлению SBAT для shim и механизма Secure Boot SVN для Диспетчера загрузки Windows.
Как обходят Secure Boot старыми shim
Проблема не в одной ошибке. Старый shim открывает сразу несколько путей.
Уязвимые загрузчики второй ступени
Каждый shim доверяет набору файлов, подписанных вшитыми в него сертификатами: сборкам GRUB 2, MokManager, резервным загрузчикам. Число таких файлов колеблется от менее чем десятка у узкоспециализированных программ до сотни у крупных дистрибутивов. Метки времени подписи и компиляции у файлов, которым доверяют найденные shim, охватывают период с 2013 по 2025 год.
Самое слабое звено – GRUB 2. Разбирая shim из Oracle Linux, исследователи нашли подписанную сертификатом Oracle сборку GRUB 2 из установочного образа Oracle Linux 7.1, затронутую CVE-2015-5281. В ней доступны команды multiboot и multiboot2, которые по своей природе загружают неподписанный код и в сборках для Secure Boot должны быть запрещены.
Эксплуатация тривиальна: не нужны повреждения памяти, цепочки ROP и обратная разработка. Требуется собрать неподписанный образ ядра, совместимый с multiboot2, и скопировать его в EFI-раздел вместе с уязвимыми shim и GRUB 2. Одной команды multiboot2 достаточно, чтобы выполнить этот код при загрузке. ESET опубликовала видео с демонстрацией на системе с включённым Secure Boot.
Демонстрация ESET: запуск неподписанного кода через старый shim из Oracle Linux при включённом Secure Boot
Игнорирование списка отозванных MOK
Разрешающий список MokList поддерживается в shim практически с самого начала, а вот отзыв через MokListX начал применяться только с версии 0.9. Сценарий атаки выглядит так:
- организация подписывает собственные загрузочные утилиты своим ключом MOK;
- в утилитах находят уязвимость, старый сертификат заносят в MokListX, выпускают новые файлы с новым ключом;
- атакующий подменяет актуальный shim на старый – например, версии 0.8 из программы Abitti;
- этот shim по-прежнему доверяет сертификатам из MokList, но не умеет читать MokListX, поэтому отозванные файлы для него остаются доверенными.
Игнорирование SBAT
Поддержка SBAT появилась в shim версии 15.3. Любая более ранняя сборка не знает о механизме: не читает политику SbatLevel и не смотрит в секцию .sbat загружаемого файла. Достаточно взять подписанный shim до версии 15.3 – например, версии 0.9 из Red Hat Enterprise Linux 7.2 – и подобрать к нему сборку GRUB 2, которую он всё ещё считает доверенной, но которая давно отозвана через SBAT.
CVE-2026-10797: подпись проверяется не там, где ищется отзыв
Файл PE с подписью Authenticode хранит длину подписи в двух независимых местах: в каталоге данных заголовка PE (IMAGE_DIRECTORY_ENTRY_SECURITY) и в структуре WIN_CERTIFICATE, которая содержит саму подпись.
В затронутых shim функция проверки отзыва и функция проверки подписи берут это значение из разных мест: первая – из заголовка подписи, вторая – из заголовка PE. Подменив структуру WIN_CERTIFICATE у загрузчика второй ступени, можно добиться того, что проверка отзыва будет сверять с dbx и MokListX посторонние данные вместо настоящей подписи. Отозванный сертификат просто не будет замечен.
Ограничения обхода:
- работает только с отзывом по сертификатам, но не по хешам;
- загрузчик второй ступени должен быть подписан сертификатом, вшитым в сам shim.
Ошибку исправили в проекте shim почти десять лет назад и подробно описали в сообщении к коммиту d241bbb, но идентификатор CVE ей не присваивали до отчёта ESET.
Затронутые продукты
Полный перечень опубликован в уведомлении CERT/CC. Отозваны shim из следующих программ:
| Разработчик и продукт | Версия shim | CVE |
|---|---|---|
| Spyrus WTGCreator | 0.7 и ниже | CVE-2026-8863 |
| Red Hat Enterprise Linux 7.2 | 0.9 | CVE-2026-10797 |
| CentOS 7.2 | 0.9 | CVE-2026-10797 |
| baramundi Management Suite (до 2024R1 включительно) | 0.8 | CVE-2026-8863 |
| WhiteCanyon/Blancco WipeDrive 8.0.0 – 8.1.3 | 0.7 | CVE-2026-8863 |
| Abitti 1 (версия 1.0), Матрикуляционная комиссия Финляндии | 0.8 | CVE-2026-8863 |
| НТЦ ИТ РОСА, ROSA Linux R9 и R10 | 0.9 | CVE-2026-8863 |
| Oracle Linux 7.2 | 0.9 | CVE-2026-8863 |
| PC-Doctor Service Center 15 и 16 | 0.9 | CVE-2026-8863 |
| openSUSE UEFI Shim loader | 0.9 | CVE-2026-8863 |
| openSUSE Shim 2.1 | 0.9 | не присвоен |
Наличия этих программ на компьютере не требуется. Атакующий приносит свою копию уязвимого файла на любую систему UEFI, где прописан сторонний сертификат Microsoft – тот же приём, что и в атаках класса BYOVD, только вместо драйвера подставляется загрузчик. Затронуты все системы UEFI со включённой сторонней подписью Microsoft; на ПК Windows 11 категории Secured-core этот параметр по умолчанию выключен.
Для атаки нужны права администратора или иная возможность изменить содержимое EFI-раздела.
Истечение сертификата Microsoft ничего не решает
Сертификат Microsoft Corporation UEFI CA 2011 истёк 27 июня 2026 года, но на проверку Secure Boot это не влияет. Пока сертификат остаётся в базе db и не отозван через dbx, все корректно подписанные им загрузчики продолжают считаться доверенными, если их хеши не занесены в список запрещённых. Именно поэтому Microsoft подписывала новые заявки старым сертификатом вплоть до даты истечения.
Сертификат действовал с 27 июня 2011 по 27 июня 2026 года. Источник: ESET
Как проверить систему
Защита сводится к установке актуального списка отзыва Microsoft. На Windows он приходит через Центр обновления автоматически: отзыв вошёл в июньский пакет обновлений, а поскольку обновления накопительные, июльский набор содержит его же.
Проверить, применён ли отзыв, можно в PowerShell с правами администратора:
$hashes = @(
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629'
)
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
$notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
"All hashes revoked in dbx!"
}Если все хеши на месте, скрипт сообщит об этом одной строкой. Иначе выведет те, которых в dbx нет.
На Linux обновление приходит через Linux Vendor Firmware Service, а состояние отзыва проверяется скриптом uefi-dbx-audit. Для Windows CERT/CC также рекомендует скрипт Check-UEFISecureBootVariables.
Администраторам стоит учитывать порядок развёртывания: сначала обновляется база разрешённых подписей db, и только затем применяется dbx. Обратная последовательность может привести к тому, что система отвергнет обновлённые загрузочные компоненты и перестанет загружаться.
Хронология раскрытия
- 16 февраля 2026 – ESET передала результаты и демонстрационный код в CERT/CC.
- 18 марта 2026 – выпуск обновления dbx и публикация назначены на 19 мая.
- 30 марта 2026 – сроки перенесены на 9 июня.
- 9 июня 2026 – отзыв в составе «Вторника Патчей», публикация уведомления CERT/CC.
- 14 июля 2026 – ESET опубликовала технический разбор.
Индикаторы компрометации ESET не публикует намеренно: уязвимые shim входят в состав легального ПО и присутствуют на тысячах систем, которые никогда не были скомпрометированы через эти загрузчики.
Проблема остаётся
Отзыв 11 уязвимых файлов устраняет конкретную проблему, но не решает главную. Лишь в 2017 году процесс подписи стал прозрачнее благодаря появлению репозитория shim-review: заявки разработчиков сначала проверяют сопровождающие проекта, и только после этого загрузчик отправляется на подпись в Microsoft. Каждый одобренный с тех пор shim задокументирован, а всё, что подписано раньше, – нет. Никто не может достоверно сказать, сколько таких «забытых» загрузчиков до сих пор остаётся в списке доверенных. То, что не внесено в каталог полностью и прозрачно, невозможно вывести из обращения.
Впрочем, исследователи ESET отмечают и положительную сторону подобных находок. Каждое новое раскрытие сокращает число забытых загрузчиков, а механизм SBAT позволяет отзывать их быстрее и эффективнее прежних методов. Следующий шаг – распространить прозрачный процесс проверки и подписи на все сторонние UEFI-приложения, а не только на shim. Именно такие компоненты уже не раз становились причиной обхода Secure Boot, что подтверждают уязвимости CVE-2022-34302, CVE-2023-28005, CVE-2024-7344 и CVE-2026-25250.