Около 200 000 устройств Framework на Linux поставлялись с легитимно подписанными компонентами UEFI Shell, содержащими команду memory modify (mm), которую можно злоупотребить для обхода Secure Boot и загрузки стойких буткитов. Об этом сообщили исследователи компании Eclypsium. Производитель подтвердил проблему и работает над исправлением; пользователям настоятельно рекомендуется установить обновления прошивки и ограничить физический доступ к устройствам до выхода всех патчей.
Суть уязвимости: опасные возможности легитимного UEFI Shell
UEFI Shell — это инструмент низкоуровневой диагностики, который поставляется на некоторых системах и подписывается для совместимости с Secure Boot. В обнаруженной конфигурации Shell содержит команду mm, предоставляющую прямой доступ на чтение/запись системной памяти. По данным Eclypsium, злоумышленник может с ее помощью вмешаться в критически важные структуры, включая переменную gSecurity2, участвующую в проверке подписи UEFI-модулей.
Почему это критично для Secure Boot
Secure Boot реализует цепочку доверия: на этапе загрузки исполняются только компоненты, подписанные доверенным поставщиком. Если же переменная gSecurity2 будет перезаписана значением NULL, проверка подписей фактически отключается. В результате неиз доверенные или вредоносные модули могут загружаться на раннем этапе, еще до запуска операционной системы, что открывает путь к буткитам и стойкому закреплению угрозы.
Масштаб и происхождение проблемы
По оценке Eclypsium, уязвимость затрагивает порядка 200 000 устройств Framework. Исследователи подчеркивают, что наличие команды mm — это не следствие компрометации цепочки поставок, а ошибка конфигурации в поставляемом UEFI Shell. Framework признала проблему и начала поэтапное исправление.
Сценарии эксплуатации: от ручных действий до автозапуска
Злоумышленник, имеющий возможность запустить UEFI Shell на целевом устройстве, может воспользоваться командой mm для модификации памяти и отключения проверок, а затем внедрить буткит. Эксперты отмечают, что атаку можно автоматизировать через сценарии автозапуска UEFI, что позволит угрозе сохраняться после перезагрузки и даже переживать переустановку ОС. Наибольший риск представляют случаи, когда у противника есть физический доступ или возможность загрузки с внешних носителей.
Рекомендации по снижению риска для владельцев устройств Framework
Установите обновления прошивки/BIOS/UEFI от Framework сразу после их выхода. Это первичная мера, блокирующая небезопасное поведение UEFI Shell и закрывающая возможность обхода Secure Boot.
До установки патчей примените дополнительные меры защиты:
Ограничьте физический доступ к устройству: используйте надежные пароли прошивки (UEFI/BIOS), настройте блокировку загрузки с внешних носителей и включите контроль загрузочного порядка.
Отключите или ограничьте UEFI Shell, если такая опция доступна в настройках прошивки, либо запретите выполнение неавторизованных UEFI-драйверов и приложений.
Удалите DB-ключ Framework через BIOS как временную меру, если обновление недоступно. Это снизит вероятность запуска подписанных производителем компонентов Shell, которые могут быть использованы в атаке. Учтите, что данная мера может повлиять на совместимость некоторых модулей — применяйте ее осознанно и при необходимости восстановите ключи после установки патчей.
Мониторинг целостности и раннего этапа загрузки
Рекомендуется отслеживать изменения политик Secure Boot и событий загрузки, использовать средства контроля целостности (включая механизмы на базе TPM и журналов измеренной загрузки), а также регулярно проверять конфигурацию UEFI на предмет несанкционированных изменений. Такие практики помогают выявлять попытки вмешательства на докернельном уровне, характерные для буткитов.
Случай с UEFI Shell на устройствах Framework наглядно демонстрирует, что даже легитимные диагностические инструменты могут становиться точками отказа в модели доверия Secure Boot. Организациям и частным пользователям стоит оперативно устанавливать обновления от производителя, минимизировать возможность запуска неподписанного кода до старта ОС и соблюдать принципы «минимально необходимого функционала» на уровне прошивки. Чем быстрее будут закрыты уязвимые конфигурации и усилены политики контроля загрузки, тем ниже риск стойких атак с использованием буткитов.
