Six vulnérabilités dans U-Boot pourraient exécuter le code avant de vérifier la signature et de compromettre toute la chaîne de confiance

Les enquêteurs du cabinet spécialisés dans la sécurité du firmware Binarly a découvert six vulnérabilités dans U-Boot, le chargeur de démarrage qui agit comme le premier code exécuté sur des équipements aussi divers que les routeurs domestiques, les caméras intelligentes et les puces de gestion de centres de données. La gravité ne vient pas seulement de la possibilité de laisser un équipement inutile: deux de ces défaillances vous permettent d'exécuter le code avant que l'image signée soit vérifiée, ce qui signifie qu'un attaquant pourrait, dans des conditions spécifiques, subvertir toute la chaîne de confiance du dispositif.

Techniquement, le problème est concentré dans la gestion du FIT (Flatted Image Tree), le conteneur que U-Boot utilise pour grouper le noyau, l'arborescence du périphérique, le ramdisk et d'autres composants. Les six erreurs sont activées alors que U-Boot partage toujours une image peu fiable et avant de valider sa signature. Les deux plus critiques (BRLY-2026-037 et BRLY-2026-038, selon les avis de Binarly) dérivent d'un appel à fdt _ get _ name - de la bibliothèque libfdt qui partage U-Boot et le noyau Linux - que sur une image déformée retourne un pointeur nul et une longueur négative, valeurs que le code ne vérifie pas et qui peut conduire à la corruption de la mémoire contrôlée par l'attaquant.

Le reste des défauts ressort du même motif : confiance dans les décalages et les tailles fournis par l'image, accepter les vieux nœuds ou formats sans validation, ou permettre à une profondeur de nidification d'épuiser la pile. Certains provoquent simplement un verrouillage du chargeur de démarrage, mais un verrou peut encore laisser une équipe sans démarrage et nécessitent une intervention physique pour refléter la mémoire.

Ces vulnérabilités ne sont pas nouvelles en termes de perspective : Binarly souligne qu'une grande partie de ce code vulnérable existe dans U-Boot depuis 2013 et reste dans des dizaines de succursales stables et dans les signatures de plusieurs fournisseurs. En outre, l'échec met en lumière une leçon répétée en matière de sécurité des bottes: la signature n'est effective que si tous les codes et métadonnées qui l'ont précédé sont traités en toute sécurité. Des incidents antérieurs tels que des pannes de boothole et d'autres analyses d'images (par exemple LogoFAIL) ont montré comment la logique de prévérification peut devenir la voie d'attaque.

Binarly publié des tests de concept et des étapes de lecture contre le bâtiment standard U-Boot, et les correctifs fusionné dans l'arbre en amont en juin. Cependant, la version de juillet de U-Boot (v2026.07) a été gelée avant qu'ils ne soient inclus et la prochaine version prévue pour octobre, v2026.10, est trop tard pour de nombreux utilisateurs. Il n'y a pas encore CVE assigné à ces six échecs, il est donc crucial de les suivre par leurs références BRLY-2026-037 à BRLY-2026-042 et d'appliquer les corrections en amont dès que possible.

Pour les fabricants et les responsables de produits basés sur U-Boot, la recommandation est immédiate : intégrer les engagements corrigés du dépôt en amont, tester fermement les flux de démarrage de leurs plateformes et préparer des mises à jour du firmware pour la distribution. Comme le patch existe déjà dans U-Boot mais n'apparaîtra pas dans la version stable immédiate, ne pas attendre le prochain tarball communautaire est une décision raisonnable.

Pour les utilisateurs finals et les administrateurs, la protection nécessite une surveillance et une atténuation pragmatiques : la surveillance des avis de sécurité des fournisseurs pour obtenir des mises à jour du firmware, segmenter et restreindre l'accès aux interfaces de gestion à distance (BMC / iDRAC / iLO etc.) et minimiser l'exposition des processus de mise à jour automatique à des réseaux peu fiables. Dans les cas où le fournisseur n'offre pas de correctifs, il convient d'évaluer des mesures temporaires telles que la désactivation des mises à jour à distance ou l'isolement de l'appareil jusqu'à ce qu'il y ait une correction officielle.

Il est important de souligner la difficulté réelle à la suite de la publication du patch: mettre à jour des millions d'appareils distribués par plusieurs fournisseurs est le véritable goulot de bouteille. Même lorsque la communauté fixe le code, le patch doit arriver correctement testé et déployé par chaque fabricant, et souvent cela nécessite du temps et des ressources que tous les acteurs ne sont pas disposés à investir avec l'urgence nécessaire.

En termes de détection, ces défaillances sont complexes : l'exécution précoce peut être laissée hors de portée des outils de sécurité standard du système d'exploitation. Par conséquent, la défense devrait prioriser la réduction des vecteurs de livraison: protéger les processus de mise à jour, renforcer l'accès à la gestion à distance et appliquer des contrôles d'intégrité et la récupération du firmware (y compris la nécessité d'un accès physique pour la récupération si possible).

Ceux qui veulent approfondir U-Boot et son écosystème peuvent consulter la documentation officielle à https: / / u-boot.org / et la spécification / documentation sur les arbres de dispositif dans l'arbre du noyau dans https: / / www.kernel / doc / html / last / devicetree /. Pour le contexte historique sur la raison pour laquelle la défaillance des chargeuses de boot est dangereuse, la recherche et l'analyse de BootHole offrent une bonne référence: https: / / www.eclypsium.com / blog / 2020 / boot-hole /.

En bref, ces six échecs indiquent à nouveau une règle de base : la sécurité de la botte est aussi forte que son maillon le plus faible dans la phase de présignature. Les fournisseurs, les intégrateurs et les administrateurs doivent agir déjà pour appliquer les corrections en amont, activer l'alerte de distribution du firmware et réduire la façon dont une image malveillante pourrait atteindre le processus de démarrage.