Шесть уязвимостей U-Boot затрагивают код, который проверяет прошивку еще до запуска операционной системы. Для разработчиков встраиваемых систем, производителей оборудования и команд ИБ это неприятный сценарий: если баг срабатывает на этапе загрузки, антивирус, EDR и прочие привычные защитные слои в этот момент еще просто не существуют.
Проблему обнаружила Binarly, а о деталях сообщает BleepingComputer. Речь идет об ошибках в механизме проверки подписей FIT-образов в U-Boot, одном из самых распространенных open source-загрузчиков в мире. Его используют в embedded Linux-устройствах, BMC на серверных платформах, сетевом оборудовании, промышленных системах, IoT и множестве других железок, которые обычно никто не вспоминает до первого инцидента.
Самое неприятное здесь не число багов, а место их жизни. U-Boot отвечает за старт системы и загрузку образов прошивки и ОС. Один из его ключевых защитных механизмов, Verified Boot, должен гарантировать, что устройство поднимет только образ, подписанный доверенным ключом. Binarly нашла шесть отдельных уязвимостей именно в логике проверки подписи FIT. Две из них потенциально позволяют добиться выполнения произвольного кода во время верификации прошивки, еще четыре можно использовать для аварийного завершения загрузчика и отказа в обслуживании.
Исследователи перечисляют шесть проблем под идентификаторами BRLY-2026-037, BRLY-2026-038, BRLY-2026-039, BRLY-2026-040, BRLY-2026-041 и BRLY-2026-042. Первая может привести к сбою U-Boot при обработке вредоносного образа и при определенных условиях дать выполнение кода. Вторая связана с повреждением памяти и тоже потенциально ведет к запуску произвольного кода в момент проверки подписи. Остальные четыре выглядят менее эффектно, но не безобидно: чтение за пределами образа, разыменование нулевого указателя, некорректная проверка внешних данных прошивки и неограниченная рекурсия, которая может просто съесть стек. Для атакующего это не обязательно «всего лишь краш»: на уровне бутлоадера любой отказ в корректной загрузке легко превращается в полноценную эксплуатационную проблему для бизнеса.
Отдельная деталь, от которой инженерам по сопровождению железа обычно хочется молча посмотреть в окно: большая часть уязвимого кода существует с версии U-Boot 2013.07. По оценке Binarly, это означает потенциальное влияние более чем на 50 стабильных релизов проекта, не считая бесконечных downstream-форков у вендоров. То есть патч в апстриме сам по себе ничего не чинит на уже проданных устройствах. Между исправлением в проекте и безопасным состоянием в продакшене лежит привычная пропасть: производитель должен подтянуть изменения в свою ветку, выпустить обновление прошивки, протестировать его на совместимость, а клиенту еще нужно это обновление реально установить. Для старых или снятых с поддержки устройств прогноз банален: они могут остаться уязвимыми навсегда.
Практический риск зависит от того, как именно устроено обновление прошивки в конкретной системе. Binarly отдельно отмечает, что физический доступ нужен не всегда. Если речь идет, например, о BMC с удаленным обновлением, атакующему достаточно уже иметь компрометированный интерфейс управления, чтобы загрузить специально подготовленный образ и попытаться использовать баг на этапе проверки. Это важная оговорка для ИТ-директоров и команд эксплуатации: сама по себе уязвимость в бутлоадере не означает «всех срочно взломают через интернет», но в цепочке после компрометации панели управления она может стать отличным усилителем атаки. Атака до старта ОС дает высокий уровень привилегий, возможность вмешаться в ранние стадии загрузки, отключить отдельные защитные механизмы и закрепиться в прошивке надолго и тихо.
Для индустрии это еще один неприятный сигнал о состоянии supply chain в прошивках. U-Boot слишком распространен, чтобы относиться к нему как к экзотике из мира embedded. Его присутствие в BMC, сетевом оборудовании и промышленных системах означает, что история касается не только производителей роутеров и IoT-датчиков, но и корпоративной инфраструктуры. Проблема типична для firmware security: уязвимость нашлась в базовом компоненте, код много лет копировался по форкам, обновления доставляются медленно, а видимость на этом уровне у большинства компаний слабая. Многие организации довольно неплохо знают, какие версии Linux или OpenSSL стоят на серверах, но хуже понимают, какой загрузчик живет внутри их контроллеров управления, стоек, шлюзов или специализированных appliances.
Хорошая новость в этой истории только одна: Binarly сообщила о проблемах мейнтейнерам U-Boot и отправила патчи по всем шести уязвимостям, а апстрим их уже принял. Плохая новость тоже одна, но весомее: дальше все упирается в дисциплину вендоров и инвентаризацию у заказчиков. Разработчикам устройств стоит срочно проверять, используется ли у них уязвимый код FIT signature verification, а корпоративным командам ИБ и инфраструктуры — требовать от поставщиков конкретных статусов по прошивкам, а не традиционного «обновление планируется». На фоне роста интереса к атакам ниже уровня ОС уязвимости U-Boot выглядят не как частный баг, а как напоминание: доверенная загрузка хороша ровно до того момента, пока доверять можно коду, который ее реализует. Подробности исходного сообщения доступны в .