zedeldi/cve-2025-47827PoC и отчет об уязвимости для CVE-2025-47827.
Доказательство концепции и отчет об уязвимости для CVE-2025-47827.
В IGEL OS до версии v11 Secure Boot может быть обойден, поскольку модуль
igel-flash-driver неправильно проверяет криптографическую подпись.
В конечном итоге поддельная корневая файловая система может быть смонтирована из
непроверенного образа SquashFS.
Неправильная проверка криптографической подписи в модуле ядра Linux igel-flash-driver
в IGEL OS 10 позволяет злоумышленнику обойти Secure Boot, загружая shim,
подписанный Microsoft 3rd Party UEFI CA, который затем загружает GRUB и уязвимое ядро,
оба подписанные IGEL Secure Boot Signing CA. После загрузки уязвимого ядра и
встроенного initramfs вредоносная корневая файловая система может быть смонтирована
из непроверенного образа SquashFS на диске.
Поскольку системный вызов kexec_load доступен в уязвимом ядре, загруженное
в данный момент ядро может быть заменено на полностью недоверенное, что практически
позволяет загрузить любую операционную систему, следуя полной цепочке доверия.
В более поздних версиях IGEL OS модуль правильно проверяет подпись образа корневой файловой системы SquashFS. Однако и уязвимое ядро, и исправленные версии подписаны одним и тем же сертификатом, что позволяет одному и тому же shim загружать как уязвимые, так и исправленные версии.
Исходная векторная строка для CVE-2025-47827 была
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
дающая оценку CVSS 8.4 (высокая).
14 октября 2025 года она была изменена на
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
снизив оценку до 4.6 (средняя).
Кроме того, исходная слабость была определена как CWE-347: Неправильная проверка криптографической подписи, но MSRC присвоил ей CWE-324: Использование ключа с истекшим сроком действия.
IGEL и Microsoft были уведомлены об этой уязвимости 6 декабря 2024 года и 31 марта 2025 года соответственно, до того, как подробности были опубликованы 29 мая 2025 года.
Поскольку IGEL OS 10 не поддерживается, а уязвимость не существует непосредственно в shim, ни одна из сторон не предложила решения. Microsoft ответила следующим образом:
После расследования мы пришли к выводу, что данное представление не соответствует определению уязвимости безопасности для обслуживания, поскольку IGEL OS v10 больше не поддерживается, а проблема заключается в модуле ядра, а не в shim. Только shim подписан сертификатом MSFT.
IGEL опубликовала уведомление о безопасности для CVE-2025-47827 2 июня 2025 года.
13 июня 2025 года я повторно сообщил об этом в Microsoft и получил следующий ответ:
Хотя ваш отчет содержал некоторую полезную информацию, он не соответствует требованиям Microsoft для уязвимости безопасности, подлежащей обслуживанию. Сообщенная проблема находится в модуле ядра, а не в shim, и только shim подписан сертификатом MSFT. kexec уже позволяет обойти Secure Boot по замыслу (Ссылка: kexec Command Line in Linux - Linux Expert Better 2025).
Это соответствовало бы критериям обслуживания MSRC, если бы проблема была в загрузочном драйвере/компоненте. Это уязвимость в драйвере ядра дистрибутива Linux. Это происходит после UEFI "ExitBootServices", что означает, что это не обход Secure Boot. Пользователь имеет только выполнение кода на уровне ОС, а не загрузку.
С момента публикации различных новостных статей относительно этой уязвимости, поддерживающие shim связались с Microsoft и IGEL для обсуждения решения.
После достижения решения 20 октября 2025 года я создал еще одно обращение в MSRC с вопросом о причине задержки отзыва этих shim, изменениях векторной строки CVSS и CWE, и почему их руководство по обновлению утверждало, что уязвимость не была публично раскрыта. Я получил следующий ответ:
Уязвимость IGEL, которая была исправлена, не является обходом Secure Boot. Это специфический для Linux обход целостности ядра и не затрагивает Windows. Shims IGEL старые и не поддерживают новую отзыв на основе SBAT. Поэтому Microsoft выпустила отзывы для защиты от потенциальных эксплойтов других уязвимостей, которые были защищены SBAT.
Jeffrey Sutherland, главный руководитель программы, ответил в PR, объяснив, что из-за отсутствия SBAT shims пришлось отозвать через DBX, и IGEL запросила дополнительное время, чтобы избежать непредвиденных последствий. Они также извинились за отсутствие поддержания связи между исследователем и вовлеченными сторонами, как того требует Скоординированное раскрытие уязвимостей.
Эксплойт обхода Secure Boot может привести к разработке необнаруживаемого bootkit/руткита на уровне ядра, что, в свою очередь, приведет к множеству последствий, таких как:
Без отзыва или ручного вмешательства Secure Boot стал бесполезным на всех машинах, доверяющих Microsoft 3rd Party UEFI CA, что является значением по умолчанию для большинства устройств на момент написания.
Если используется для kexec, эта уязвимость может быть использована для тихой
и вредоносной модификации легитимной системы без воздействия на Secure Boot.
Ядро может быть полностью заменено, что позволит вредоносному коду выполняться на уровне ядра, предоставляя неограниченный доступ ко всем системным ресурсам, включая память, процессор и подключенные устройства.
Это позволит выгружать ключи шифрования из памяти, выполнять вредоносные процессы без ограничений и избегать обнаружения вредоносного ПО.
