31 октября 2026Команда Сарнас

Переполнение в PXE-драйвере EDK II: один ICMP-пакет на этапе сетевой загрузки

В эталонном коде UEFI-прошивок EDK II обнаружено критическое переполнение буфера, позволяющее атакующему в сети повредить память машины единственным ICMP-пакетом во время PXE-загрузки. Ошибка прожила в коде около 16 лет, затрагивает прошивки почти всех производителей и даёт исполнение кода до проверок Secure Boot.

В наборе компонентов TianoCore EDK II, на основе которого производители собирают UEFI-прошивки, нашли переполнение буфера в драйвере сетевой загрузки PXE (UefiPxeBcDxe). Этот драйвер во время такой загрузки принимает сообщения об ошибках ICMP и копирует каждое в фиксированную область памяти размером 504 байта. Уязвимость получила идентификатор CVE-2026-97631 и оценку 9,5 из 10 по CVSS 4.0. TianoCore опубликовал предупреждение 22 октября, новостные публикации датированы 28 и 29 октября 2026 года. Ошибочный цикл копирования присутствует в коде с коммита, добавленного в ноябре 2010 года, — около 16 лет.

Что именно изменилось

Изменился сам драйвер: в исходный код EDK II внесли исправление, которое не даёт сообщению выйти за пределы области памяти в 504 байта — всё, что длиннее, отбрасывается, а не перезаписывает соседнюю память. Правка попала в основную ветку разработки 15 октября, но ни один стабильный релиз EDK II её пока не содержит — уязвимы версии вплоть до edk2-stable202608 (дата выпуска — 21 августа).

Механика ошибки такая. При PXE драйвер принимает ICMP и копирует каждое в фиксированную область памяти размером 504 байта. Проверки размера при копировании неверны в обеих реализациях обработчика — для IPv4 и для IPv6, — поэтому сообщение длиннее 504 байт выходит за границы области и перезаписывает соседнюю память данными, выбранными атакующим. Переполнение затрагивает обработчики обоих протоколов и позволяет повредить внутренние структуры прошивки.

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

Как было раньше

Сетевая загрузка в UEFI устроена так: машина загружает стартовый образ из сети вместо локального диска, и этим занимается драйвер UefiPxeBcDxe. PXE-загрузка включена по умолчанию в стандартной сборке EDK II.

Дефектный цикл копирования присутствует в коде с коммита ноября 2010 года. Проекты фаззинга, запущенные после PixieFail для поиска новых ошибок в этом коде, данную ошибку не обнаружили.

Почему это сделали

Публичное раскрытие первоначально планировали на январь 2027 года. План нарушился 28 сентября, когда pull request в EDK II, подписанный сотрудником AMI, публично описал уязвимость по номеру CVE и включил исправление. После этого TianoCore опубликовал предупреждение 22 октября — на недели раньше согласованного срока.

Что это меняет на практике

Уязвимость находится в эталонном коде, на котором строят прошивки почти все вендоры UEFI, включая независимых производителей BIOS AMI, Insyde и Phoenix, а также усиленный форк Microsoft Project Mu. Project Mu уже перенёс исправление в релизные ветки и выпустил тегированные сборки 26 октября. Код поставляют и Linux-дистрибутивы: Red Hat указывает пакет edk2 в RHEL 8, 9 и 10 как затронутый и пока не исправленный, SUSE и Debian помечают свои аналогичные пакеты так же.

Затронуты организации, чьи машины загружаются по сети, — прежде всего серверы и оборудование ЦОД. Компьютеры, которые запускаются исключительно с локального диска, этому способу эксплуатации не подвержены.

Простейший исход атаки — сбой: загрузка зависает, и машина не стартует. Выполнение кода сложнее и менее надёжно: атакующий, знающий точную сборку прошивки, может заставить прошивку выполнить его собственный код, поэтому эксплойт строится под конкретную сборку. Такой код исполняется внутри прошивки раньше, чем Secure Boot и другие проверки при загрузке что-либо проверили, — эта временная позиция и делает уязвимость серьёзной. Код выполняется один раз и сам по себе не переживает перезагрузку, но одного запуска достаточно, чтобы установить другой код, стартующий при каждой загрузке, или подменить загружаемые компоненты.

Сама по себе уязвимость не ломает Secure Boot и не является способом проникновения в сеть. Реалистичный атакующий — инсайдер или тот, кто уже получил низкоуровневое присутствие в локальной сети; Red Hat и SUSE оценивают эксплуатацию как атаку с соседней позиции в сети — из того же сегмента локальной сети, а не через открытый интернет. По словам HD Moore, это может позволить сломать шифрование диска при кратковременном сетевом доступе.

До выхода обновления прошивки официального обходного пути нет. Операторам, которым PXE не нужен, предлагается его отключить, чтобы снизить риск; также советуют следить за сетевым трафиком и логами во время загрузки. Исправление не требует отзыва сертификатов или ключей, но установить его можно только когда производитель прошивки выпустит обновление BIOS/UEFI на его основе.

Ограничения и открытые вопросы

AMD, Phoenix Technologies, AMI, Microsoft и Amazon не ответили на вопросы издания до публикации, TianoCore тоже не ответил, поэтому статус их продуктов остаётся неясным. Сколько поставляемых продуктов несут уязвимый код, неизвестно. Intel заявила, что ни один из её продуктов, «currently under security support», не известен как затронутый и что она не включает затронутую функциональность EDK2 в свой эталонный код, хотя OEM-производитель платы или системный интегратор мог её добавить. Arm заявила, что уязвимость «is not directly applicable to Arm's product portfolio».

Воспроизводимость эксплойта ограничена: его нужно строить под конкретную сборку прошивки, а получение выполнения кода заметно сложнее и менее надёжно, чем сбой загрузки. Пока производитель прошивки не выпустит обновление BIOS или UEFI, собранное из исправленного кода, оператору сервера нечего устанавливать.