Уязвимость позволяет обойти UEFI Secure Boot, затронуты миллионы устройств

Уязвимость позволяет обойти UEFI Secure Boot, затронуты миллионы устройств

Уязвимость позволяет обойти UEFI Secure Boot, затронуты миллионы устройств

Исследователи из 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 в прошивке — особенно для переменных, влияющих на загрузку.

В России начало массово выходит из строя оборудование в старых ЦОД

В российских центрах обработки данных (ЦОД), введённых в эксплуатацию 10 и более лет назад, начались массовые отказы оборудования. Причина — выработка ресурса на фоне сложностей с поставками запасных частей из-за рубежа и отсутствия необходимых складских запасов.

По оценке отраслевых аналитиков, опрошенных РБК, проблема затрагивает примерно каждый пятый коммерческий ЦОД. Особенно остро ситуация проявляется в сравнительно небольших дата-центрах, а также в локальных серверных в компаниях.

Руководитель направления сервиса инженерных систем «К2Теха» Денис Полуэктов отметил, что в первой половине 2025 года запросов на устранение аварий в ЦОД, связанных с проблемами инженерной инфраструктуры, не поступало. Однако в начале 2026 года число таких обращений уже превысило 10. Состояние инженерной инфраструктуры во всех этих случаях специалист охарактеризовал как «предсмертное».

Схожую оценку дал и заместитель генерального директора по инфраструктуре интегратора «Ультиматек» Павел Приедитис. По его словам, все заявки связаны с объектами, где инфраструктура была установлена 10 и более лет назад. Именно на этот срок обычно приходится завершение жизненного цикла такого оборудования.

Член оргкомитета Профессиональной ассоциации в сфере облачных технологий (RCCPA) Антон Салов оценил долю коммерческих ЦОД, столкнувшихся с этой проблемой, в 20%. В первую очередь речь идёт о системах бесперебойного питания, дизель-генераторах и подсистемах климат-контроля.

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

В 2026 году уже произошло как минимум два заметных инцидента, связанных с работой ЦОД. Так, 27 марта не работал ЦОД правительства Белгородской области, однако в том случае причиной стала авария на линии электроснабжения. А 16 марта масштабный сбой произошёл у «Яндекса», причём он затронул и сторонние компании, использующие его инфраструктуру.

RSS: Новости на портале Anti-Malware.ru