Изследователи от фирмата за сигурност на фърмуера Binarly откриха шест нови уязвимости в U-Boot – малката програма, която стартира хардуер от всякакъв тип, като домашни рутери, смарт камери и управляващи чипове в сървъри за центрове за данни.
Четири от грешките могат да сринат устройството. Останалите две биха могли да позволят на нападател, който вмъкне зловредно изображение преди зареждащата програма (bootloader), да изпълни собствен код, преди устройството да е потвърдило, че софтуерът е автентичен.
Тази последна част е ключова. Зареждащата програма се изпълнява преди операционната система, така че уязвимост тук може да компрометира всичко, което се зарежда след нея. Всички шест грешки се достигат, докато U-Boot все още чете недоверено изображение, преди да е проверил неговия подпис.
U-Boot може да обединява ядро, дърво на устройствата (device tree), ramdisk и други компоненти за стартиране в един пакет, наречен FIT (Flattened Image Tree), и проверява цифровия подпис на този пакет, преди да предаде контрола.
Binarly потърси слаби места в тази проверка и откри шест. По-голямата част от уязвимия код присъства в U-Boot от версия v2013.07 насам, обхващайки над 50 стабилни версии, и също така съществува в множество фърмуери на различни производители, изградени на базата на U-Boot.
Уязвимостите се проследяват като доклади на Binarly от BRLY-2026-037 до BRLY-2026-042. Все още не са присвоени CVE идентификатори. Те се разделят на две групи: две, които могат да изпълняват код, и четири, които само сриват системата.
Двете критични грешки са BRLY-2026-037 и BRLY-2026-038, като и двете произлизат от една непроверена стойност. U-Boot извиква функцията fdt_get_name (за търсене в библиотеката за парсване на device-tree), която при повредено изображение връща нулев указател (null pointer) и отрицателна дължина. U-Boot използва и двете стойности без проверка.
Едната грешка следва нулевия указател в копиране на паметта, което на устройства с картиран адрес нула се превръща в препълване на буфера в стека. Другата използва отрицателната дължина в аритметика с указатели, която се движи назад, докато не презапише запазен адрес за връщане. При подходящо разпределение на паметта, всяка от тях може да предаде контрола на код, предоставен от нападателя.
Другите четири уязвимости само сриват зареждащата програма. BRLY-2026-039 и BRLY-2026-041 четат извън края на изображението, като се доверяват на размер или отместване, контролирани от нападателя. BRLY-2026-040 дереферира нулев указател, върнат без проверка от по-стар формат на изображението. BRLY-2026-042 изчерпва стека поради силно вложена структура на изображението, което кара ранен етап на валидация да се извиква рекурсивно, докато паметта свърши.
Binarly публикува демонстрационни изображения (proof-of-concept) и стъпки за възпроизвеждане на всяка уязвимост срещу стандартни компилации на U-Boot. Не се съобщава за реални атаки с използване на тези уязвимости.
От шестте, двете уязвимости, свързани с компрометиране на паметта, са с приоритет: сривът може да извади устройството от строя, но изпълнението на код при стартиране може да подкопае цялата верига на доверие.
В най-лошия случай възстановяването на устройство, което не иска да стартира, изисква физически достъп и пренаписване на чипа с памет с чисто изображение. Изпълнението на код е още по-опасно – софтуерът, който се стартира толкова рано, се намира под операционната система, където обичайните инструменти за сигурност не могат да го засекат.
Трудността за нападателя е в доставянето на зловредния код: тези грешки се проявяват само когато зловредното изображение достигне пътя на зареждане, което обикновено изисква физически достъп или привилегирован достъп до системата. Този достъп обаче невинаги е локален.
В предишна работа върху контролерите за управление на сървъри на Supermicro, същият изследовател от Binarly показа, че нападател с отдалечен достъп до интерфейса за управление може да злоупотреби с процеса на актуализация на самото устройство, за да запише зловредно изображение, без да докосва хардуера физически.
Все още няма стабилна версия на U-Boot с корекция, така че производителите и поддържащите продукти, базирани на U-Boot, не трябва да чакат: те трябва да внедрят корекциите веднага, следвайки връзките в докладите на Binarly, като ги проследяват по ID на доклада, тъй като все още липсват CVE номера.
U-Boot обедини шестте корекции през юни, но юлската версия (v2026.07) вече беше замразена през април и беше доставена без тях; следващата версия v2026.10 се очаква чак през октомври.
Всички останали потребители използват устройства, създадени от трети страни. За тях корекцията трябва да дойде под формата на фърмуерна актуализация от производителя на продукта. Това е нещото, за което трябва да се следи.
Подобен проблем е възниквал и преди. Същата логика за проверка на подписа беше засегната месеци по-рано от CVE-2026-33243, която U-Boot коригира през април; свързаната зареждаща програма barebox, използваща същите инструменти за изображения, също беше засегната.
При тази грешка, свойство, предназначено само да описва какво покрива подписът, само по себе си не беше подписано, така че подправено изображение можеше да подмени части, които никога не са били проверявани. Помощната функция зад двете най-опасни грешки тук, fdt_get_name, идва от libfdt – библиотеката за дърво на устройствата, която U-Boot споделя с ядрото на Linux, barebox и други. Същата грешка с непроверена върната стойност може да се появи навсякъде, където се използва този код.
LogoFAIL, която медиите отразяваха през 2023 г., беше набор от грешки при парсване на изображения в компютърния фърмуер, които позволяваха на код на нападател да се изпълни по време на стартиране, преди Secure Boot да успее да провери каквото и да е, засягайки почти всяка голяма марка компютри. Подписът получава цялото внимание, но грешките продължават да се появяват в кода, който се изпълнява преди него.