Уязвимость выполнения кода в прошивке UEFI угрожает большинству серверов на планете

Беда прилетела

Защитники по всему миру получают очередное бремя — ещё одна уязвимость выполнения кода, но теперь в загрузочной прошивке, которую используют большинство производителей серверов и центров обработки данных.

Уязвимость с рейтингом серьезности 9.5 из 10 находится в TianoCore EDK II — открытом исходном коде, который производители оборудования и облачные провайдеры используют для создания UEFI-прошивки, выполняемой во время загрузки системы. Годом ранее представитель UEFI Forum назвал EDK2 «главным решением и реализацией UEFI спецификаций». Практически все поставщики UEFI (иногда их называют IBV, независимые поставщики BIOS), включая AMI, Insyde и Phoenix, широко используют эталонный код. Project Mu, затвердённая версия EDK2 от Microsoft, также использовал код с уязвимым компонентом.

Уязвимость, отслеживаемая как CVE-2026-97631, — это ошибка повреждения памяти в компоненте ICMP, которую злоумышленники могут использовать для выполнения вредоносного кода, запускающегося до того, как операционная система и прошивка смогут развернуть защиту наподобие Secure Boot, устанавливающего цепочку доверия для всего кода, включая Trusted Platform Module (TPM), загружаемый во время старта. Хотя финальные полезные нагрузки CVE-2026-97631 не обладают персистентностью — они выполняются только один раз — они дают злоумышленникам широкие возможности для установки других полезных нагрузок, которые запускаются при каждой ранней загрузке.

Кот выпущен из мешка

Стороны, обнаружившие CVE-2026-97631 — Алекс Матросов из Anthropic и Дэн Холмс из Google — договорились держать это в секрете до координированного раскрытия, запланированного на январь. AMI, производитель материнских плат и другого оборудования, опубликовал этот pull request прошлым месяцем с деталями уязвимости и исправлением кода. Когда пост привлёк внимание обнаруживших её специалистов, члены TianoCore Project опубликовали открытый совет на прошлой неделе.

Имея в открытом доступе исправленный код, для продвинутых хакеров будет тривиально понять, как срабатывает уязвимость, и создать рабочие эксплойты. Усугубляя срочность, исправление уязвимостей UEFI в миллионах устройств, проданных и используемых тысячами производителей оборудования и облачных провайдеров, утомительно и требует много времени. Новость об уязвимости появилась всего шесть дней спустя после другого неудачного раскрытия — на этот раз касающегося критической уязвимости выполнения кода в языке программирования PHP.

«Эта уязвимость в парсере ICMP сетевого стека EDK2 интересна с точки зрения того, как она влияет на цепочку доверия и более широкую экосистему, — рассказал HD Moore, создатель Metasploit и главный научный сотрудник компании безопасности Dragos. — Злоумышленник, намеревающийся скомпрометировать близлежащую конечную точку или сервер, мог бы использовать этот баг, чтобы перехватить поток программы в момент, когда процесс загрузки всё ещё имеет доступ к чувствительным компонентам, таким как TPM конечной точки. Это может быть использовано для взлома шифрования диска в случаях, когда злоумышленник имеет кратковременный доступ в сеть (и это было бы ещё проще при краже устройства)».

CVE-2026-97631 — это ошибка переполнения буфера 16-летней давности в драйвере PXE-Base Code (NetworkPkg/UefiPxeBcDxe), отвечающего за возможность серверов, оборудования хранения и других устройств загружаться с помощью кода, загруженного из локальной сети. Во время этого процесса — известного как среда предварительного выполнения загрузки — драйвер использует сетевой слушатель для мониторинга ошибок ICMP. Поскольку драйвер не ограничивает размер копирования памяти в 504 байта, перезаписывая прилегающие данные, внутренний человек или хакер, получивший низкоуровневый доступ к локальной сети, может отправить сообщение об ошибке, которое добавляет код сверх этого лимита. UEFI-модуль, работающий на процессоре, затем повреждается.

Как гласит официальный совет:

Во время загрузки по сети драйвер PXE Base Code (NetworkPkg/UefiPxeBcDxe) держит открытым запрос получения на предмет сообщений об ошибках ICMP и копирует каждое полученное сообщение в фиксированное поле из 504 байт Mode.IcmpError своей приватной структуры контекста. Обработка границ цикла копирования некорректна как в обработчиках IPv4, так и IPv6 (PxeBcIcmpErrorDpcHandle и PxeBcIcmp6ErrorDpcHandle): для сообщения длиннее 504 байт он всё ещё копирует байты в поле и продвигает указатель назначения на совокупную, а не на длину отдельного фрагмента, поэтому увеличенное сообщение записывает контролируемые злоумышленником байты за пределы поля. Ничто на более ранних стадиях пути получения не ограничивает длину сообщения.

Вредоносную ошибку можно доставить через простой unicast из любого расстояния в сети на IP-адрес целевого устройства, если это происходит во время последовательности загрузки PXE. Злоумышленник может вызвать отказ в обслуживании, заставив последовательность загрузки зависнуть. Когда злоумышленник знает, какая версия микрокода используется, он может создать «поддельное событие», которое выполнит вредоносный код на процессоре в его среде UEFI. Код выполняется в ring 0, самом привилегированном уровне выполнения процессора. Поскольку эксплойты обходят процессы аттестации, предназначенные для криптографического доказательства удалённым серверам безопасности оборудования, они представляют ключевую возможность для повышения ограниченных привилегий.

Очередной вечный баг

CVE-2026-97631 пополняет длинный список ранее обнаруженных уязвимостей в UEFI или коде, с ней тесно взаимодействующем. Самая серьёзная из них, LogoFail, проистекала из логотипов в UEFI практически каждого производителя оборудования. Ошибки рендеринга позволяли злоумышленникам подорвать цепочку доверия, которую UEFI обеспечивает, и установить вредоносные компоненты до загрузки ОС или запуска Secure Boot. PixieFail была уязвимостью, похожей на CVE-2026-97631. Она также стала результатом неправильной работы PXE-загрузки в EDK2. После обнаружения уязвимости исследователи провели несколько проектов фаззинга, предназначенных для обнаружения других критических ошибок в библиотеке открытого кода. Похоже, эти усилия не выявили этот последний баг.

Прочие недавно обнаруженные уязвимости UEFI включают:

• PKFail, отказ цепи поставок из-за ключей тестовой платформы, не предназначенных для производства, открытых более десяти лет, прежде чем их обнаружили, используемых в сотнях моделей устройств
• BootHole
• Bootkit и
• BlackLotus

Как и CVE-2026-97631, эксплуатация или использование этих полезных нагрузок привлекательно, потому что позволяет злоумышленникам заразить машины на ранней стадии загрузки, до загрузки TPM и других защит, чтобы они могли нанести максимальный ущерб. Учитывая повсеместность CVE-2026-97631, Moore отмечает, что это вероятно «вечный» баг, который будет сохраняться в системах, вышедших из поддержки.

Есть важные оговорки и ограничения на эксплуатацию этой последней уязвимости. Как отмечено, необходим какой-то уровень контроля над локальной сетью. Это вероятно ограничивает эксплуатацию внутренними лицами или злоумышленниками, такими как государства-нарушители или операторы программ-вымогателей, которым удалось получить низкоуровневый доступ внутрь сети и которые ищут способ повысить системные права. Нет пока свидетельств того, что CVE-2026-97631 предоставляет начальную точку входа в сеть. Есть и другие препятствия.

«Для эксплуатации самой уязвимости злоумышленник должен угадать конкретные адреса в целевой системе, поэтому это не то, что можно просто направить на любую цель и получить RCE на разнородном наборе устройств, но это нужно настроить для каждой версии модели/конфигурации, поскольку адреса будут меняться в зависимости от них, — рассказал Ars Джесси Майкл, главный исследователь компании безопасности прошивки Eclypsium. — В отличие от некоторых предыдущих высокопрофильных уязвимостей типа BootHole, Black Lotus и Baton Drop, эта уязвимость может быть исправлена базовым исправлением кода, что потребует развёртывания обновления BIOS/UEFI, но им не придётся иметь дело с отзывами, обновлениями ключей pk/kek/db/dbx или обеспечением обновления ОС и носителей подготовки, как это требуется при обходах Secure Boot в самом загрузчике».

CVE-2026-97631 не влияет на пользователей домов и малых офисов, или любых других пользователей, которые загружают свои устройства исключительно с жёстких дисков. Вместо этого она применяется только к организациям с машинами, которые загружаются из локальных сетей или, возможно, из подключённых к интернету ресурсов. Даже тогда целевая прошивка должна полагаться на EDK2, а не на другую реализацию, и использовать функциональность PXE (которая включена по умолчанию).

По словам Intel, ни один из его «коммерческих продуктов, находящихся под текущей поддержкой безопасности», не оказывается затронут. «Intel не включает затронутую функциональность EDK2 в свой эталонный код, хотя она может быть интегрирована поставщиком материнской платы OEM или производителем системы», добавила компания. Она рекомендовала клиентам обратиться к своему производителю системы за конкретным руководством. Однако открыто доступный эталонный код Intel ссылается на EDK2. Кроме того, TianoCore заявил, что каждый выпущенный Intel набор для разработки UEFI «является полностью проверенной реализацией для конкретной редакции исходного кода EDK II». Множество других документов Intel также ссылаются на EDK2.

Arm тем временем ответила на набор вопросов следующим: «CVE-2026-97631 не имеет прямого применения к портфелю продуктов Arm». Как и Intel, прошивка, которую компания предоставляет, также широко использует EDK2. TianoCore также задокументировала зависимость Arm от EDK2.

Хотя возможно, что некоторые платформы свободны от кода EDK2, разумно, чтобы пользователи всех серверов выяснили, влияет ли на них CVE-2026-97631.

Вопросы, отправленные AMD, Phoenix Technologies, AMI, Microsoft и Amazon — вероятно, некоторым из других крупнейших затронутых организаций — остались без ответа на момент публикации этого поста. Без конкретных ответов на вопросы об использовании EDK2 организациями наподобие этих, невозможно сказать, какие устройства затронуты и как, и какие действия, если вообще какие-то, эти организации или их пользователи должны предпринять. Представители проекта TianoCore тоже не ответили.

Некоторые читатели вероятно будут разочарованы отсутствием деталей. Иногда — особенно в случаях неудачного раскрытия, нарушившего эмбарго месяцы раньше запланированного срока — невозможно избежать отсутствия действенной информации в первоначальном докладе.

Затронутые стороны должны обратиться к производителю прошивки, используемой для загрузки их систем, и попросить руководство. Сверх этого, они должны рассмотреть отключение возможности загрузки по сети как минимум временно, если это возможно. Конфигурации прошивки всегда должны включать функции безопасности, такие как TPM и Secure Boot, когда это возможно, хотя эти защиты не защищают от этой конкретной угрозы. Также рекомендуется мониторить логи на предмет признаков попыток эксплуатации.