Исследователи из BINARLY обнаружили новую серьёзную уязвимость в механизме UEFI Secure Boot — той самой системе, которая должна защищать компьютер ещё до загрузки ОС. Уязвимость получила идентификатор CVE-2025-3052 и высокий балл 8.2 по шкале CVSS.
Уязвимый компонент — это файл Dtbios-efi64-71.22.efi, который подписан Microsoft UEFI CA 2011. А значит, считается доверенным практически на всех современных компьютерах, будь то Windows или Linux.
BINARLY выяснили, что приложение неправильно работает с переменной NVRAM под названием IhisiParamBuffer. Это буфер, откуда модуль слепо выполняет множественные записи в память. А значит — злоумышленник может заранее положить туда нужный адрес, и модуль в момент загрузки выполнит запись по произвольному адресу в памяти.
В демонстрации PoC исследователи показали, как злоумышленник с правами администратора может подменить критический указатель на структуру gSecurity2, которая и отвечает за включённость Secure Boot. Если «обнулить» этот указатель в нужный момент — можно полностью отключить Secure Boot, а дальше — загрузить любой неподписанный модуль. Хоть буткит, хоть начальный вредонос.
Почему это опасно?
Самое тревожное — уязвимый бинарник подписан Microsoft и загружен в VirusTotal, а значит, уже гуляет по интернету. Более того, сертификат Microsoft UEFI CA 2011 доверяется подавляющим большинством систем, где активирован Secure Boot. Это делает атаку масштабируемой — потенциально затронуто миллионы устройств.
Однако многое зависит от конкретной реализации BIOS. Например, в прошивках от Insyde доступ к переменным NVRAM может быть ограничен — но даже это не спасает, если в системе найдётся другая брешь.
Как выразились в BINARLY:
«Эта уязвимость затрагивает все устройства, где выполняется исходное условие цикла и где доверяют сертификату Microsoft UEFI CA 2011».
BINARLY советует следующее:
- Добавить хеш уязвимого модуля в UEFI-список отзыва (dbx), чтобы заблокировать его загрузку.
- Удалить уязвимый код из приложения — чтобы прекратить любые небезопасные записи из переменных NVRAM.
- Проверить защиту NVRAM в прошивке — особенно для переменных, влияющих на загрузку.
