Fedora. Для устранения проблем в GRUB2 недостаточно просто обновить пакет, требуется также сформировать новые внутренние цифровые подписи и обновлять инсталляторы, загрузчики, пакеты с ядром, fwupd-прошивки и shim-прослойку.
Выявленные уязвимости:
- CVE-2025-61661 — запись за пределы выделенного буфера в функции grub_usb_get_string(), которая может быть эксплуатирована при обработке строк в кодировке UTF-8 и UTF-16, передаваемых при подключении USB-устройств. Проблема вызвана тем, что буфер выделялся на основании размера строки, указанного в первом сообщении от USB-устройства, в размер при выполнении преобразования кодировки вычислялся на основе последующих операций чтения c USB-устройства. Соответственно, для атаки можно использовать модифицированное USB-устройство, изначально возвращающее заниженное значение размера.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — отсутствие очистки обработчиков команд «normal», «normal_exit», «net_set_vlan» и «gettext» при выгрузке модулей «normal», «net» и «gettext», создающее условия для обращения к памяти после её освобождения (use-after-free) в случае выполнения отмеченных команд после выгрузки соответствующих модулей. Похожие уязвимости также найдены для команд «functional_test» и «all_functional_test», но им не присвоены CVE-идентификаторы, так как данные команды входят в состав тестовой библиотеки и не должны включаться в рабочие сборки.
- CVE-2025-54771 — ошибка при подсчёте ссылок на структуры «fs» в функции grub_file_close(), приводящая к обращению к памяти после её освобождения (use-after-free).
В большинстве Linux-дистрибутивов для верифицированной загрузки в режиме UEFI Secure Boot используется небольшая прослойка shim, заверенная цифровой подписью Microsoft. Данная прослойка верифицирует GRUB2 собственным сертификатом, что позволяет разработчикам дистрибутивов не заверять каждое обновление ядра и GRUB в Microsoft. Уязвимости в GRUB2 позволяют добиться выполнения своего кода на этапе после успешной верификации shim, но до загрузки операционной системы, вклинившись в цепочку доверия при активном режиме Secure Boot и получив полный контроль за дальнейшим процессом загрузки, например, для загрузки другой ОС, модификации компонентов операционной системы и обхода защиты Lockdown.
Для блокирования уязвимости без отзыва цифровой подписи дистрибутивы могут использовать механизм SBAT (UEFI Secure Boot Advanced Targeting), поддержка которого реализована для GRUB2, shim и fwupd в большинстве популярных дистрибутивов Linux. SBAT разработан совместно с Microsoft и подразумевает добавление в исполняемые файлы компонентов UEFI дополнительных метаданных, которые включают информацию о производителе, продукте, компоненте и версии. Указанные метаданные заверяются цифровой подписью и могут отдельно включаться в списки разрешённых или запрещённых компонентов для UEFI Secure Boot.
SBAT позволяет блокировать использование цифровой подписи для отдельных номеров версий компонентов без необходимости отзыва ключей для Secure Boot. Блокирование уязвимостей через SBAT не требует использования списка отозванных сертификатов UEFI (dbx), а производится на уровне замены внутреннего ключа для формирования подписей и обновления GRUB2, shim и других поставляемых дистрибутивами загрузочных артефактов. До внедрения SBAT, обновление списка отозванных сертификатов (dbx, UEFI Revocation List) было обязательным условием полного блокирования уязвимости, так как атакующий, независимо от используемой операционной системы, мог для компрометации UEFI Secure Boot использовать загрузочный носитель со старой уязвимой версией GRUB2, заверенной цифровой подписью.
Источник: http://www.opennet.ru/opennews/art.shtml?num=64298