Sechs Schwachstellen in U-Boot könnten Code ausführen, bevor Sie die Signatur überprüfen und die gesamte Vertrauenskette beeinträchtigen

Firm's Ermittler spezialisiert auf Firmware-Sicherheit Binarly haben sechs Schwachstellen in U-Boot entdeckt, das Start-up-Ladegerät, das als erster Code fungiert, der auf so vielfältigen Geräten wie heimische Router, Smart-Kameras und Datacenter-Management-Chips ausgeführt wird. Gravity kommt nicht nur durch die Möglichkeit, eine nutzlose Ausrüstung zu verlassen: zwei dieser Fehler ermöglichen es Ihnen, Code auszuführen, bevor das signierte Bild überprüft wird, was bedeutet, dass ein Angreifer unter bestimmten Bedingungen könnte, Subvertieren der gesamten Vertrauenskette des Gerätes.

Technisch konzentriert sich das Problem auf die Verwaltung von FIT (Flatted Image Tree), den Container, den U-Boot verwendet, um Kernel, Gerätebaum, Ramdisk und andere Komponenten zu gruppieren. Die sechs Fehler werden aktiviert während U-Boot noch ein unzuverlässiges Bild und vor der Validierung seiner Signatur. Die beiden kritischsten (BRLY-2026-037 und BRLY-2026-038, laut Binarlys Ankündigungen) stammen von einem Anruf auf fdt _ get _ name - aus der Bibliothek, die U-Boot und den Linux-Kernel teilen - dass auf einem formierten Bild einen Nullzeiger und eine negative Länge zurückgibt, Werte, die der Code nicht überprüft und die zu Speicherkorruption führen kann, gesteuert durch den Angreifer.

Der Rest der Fehler kommt aus dem gleichen Muster: Vertrauen in Offsets und Größen, die durch das Bild bereitgestellt werden, akzeptieren alte Knoten oder Formate ohne Validierung, oder erlauben eine Nisttiefe, um den Stack auszuschöpfen. Einige verursachen einfach eine Sperrung des Boot-Ladegeräts, aber ein Schloss kann noch ein Team ungestartet lassen und erfordern physische Eingriffe, um Gedächtnis zu reflektieren.

Diese Schwachstellen sind im Hinblick auf die Perspektive nicht neu: Binarly weist darauf hin, dass in U-Boot seit 2013 viel von diesem verletzlichen Code existiert und in Dutzenden von stabilen Zweigen und in Unterschriften von mehreren Lieferanten bleibt. Darüber hinaus unterstreicht der Ausfall eine wiederholte Lektion in der Boot-Sicherheit: die Signatur ist nur wirksam, wenn der gesamte Code und die Metadaten, die ihm vorausgegangen sind, sicher behandelt werden. Frühere Vorfälle wie Boothole und andere Bildparser-Versagen (z.B. LogoFAIL) haben gezeigt, wie die Vorverifikationslogik die Angriffsroute werden kann.

Binarly veröffentlichte Konzepttests und Wiedergabeschritte gegen U-Boot Standard-Gebäude und die Patches fusionierten im Juni in den vorgelagerten Baum. Die Juli-Version von U-Boot (v2026.07) wurde jedoch eingefroren, bevor sie aufgenommen wurden und die nächste für Oktober geplante Veröffentlichung v2026.10 ist für viele Benutzer zu spät. Es gibt noch nicht CVE diesen sechs Fehlern zugeordnet, so ist es entscheidend, ihnen durch ihre BRLY-2026-037 Referenzen auf BRLY-2026-042 zu folgen und die vorgelagerten Korrekturen so bald wie möglich anzuwenden.

Für Hersteller und Betreuer von U-Boot-basierten Produkten ist die Empfehlung sofort: Integrieren Sie die korrigierten Verpflichtungen aus dem Upstream-Repository, testen Sie die Bootströme ihrer Plattformen und erstellen Sie Firmware-Updates für die Distribution. Da der Patch bereits in U-Boot existiert, aber nicht in der sofort stabilen Version erscheinen wird, nicht warten auf die nächste Gemeinschaft tarball ist eine vernünftige Entscheidung.

Für Endbenutzer und Administratoren benötigt der Schutz eine pragmatische Überwachung und Minderung: Überwachung von Lieferantensicherheitshinweisen, um Firmware-Updates zu erhalten, den Zugriff auf Remote-Management-Schnittstellen (BMC / iDRAC / iLO und dergleichen) zu segmentieren und die Exposition von automatischen Update-Prozessen auf unzuverlässige Netzwerke zu minimieren. In Fällen, in denen der Lieferant keine Patches anbietet, ist es angebracht, vorübergehende Maßnahmen wie das Abschalten von Remote-Updates oder das Abtrennen des Geräts zu bewerten, bis eine offizielle Korrektur vorliegt.

Es ist wichtig, die reale Schwierigkeit nach der Veröffentlichung des Patches zu betonen: Millionen von Geräten, die von mehreren Lieferanten verteilt werden, zu aktualisieren ist der echte Flaschenhals. Auch wenn die Gemeinschaft den Code festlegt, muss der Patch von jedem Hersteller richtig getestet und eingesetzt werden, und oft erfordert das Zeit und Ressourcen, die nicht alle Akteure bereit sind, mit der notwendigen Dringlichkeit zu investieren.

Diese Fehler sind nachweislich komplex: Eine frühzeitige Ausführung kann aus der Reichweite von Standard-Betriebssystem-Sicherheitswerkzeugen ausgeschlossen werden. Daher sollte die Verteidigung die Reduktion von Liefervektoren priorisieren: Aktualisierungsprozesse schützen, Remote-Management-Zugang straffen und Integritätskontrollen und Firmware-Recovery anwenden (einschließlich der Notwendigkeit für den physischen Zugang zur Wiederherstellung, wo möglich).

Diejenigen, die U-Boot und sein Ökosystem vertiefen wollen, können die offizielle Dokumentation bei https: / / u-boot.org / und die Spezifikation / Dokumentation der Gerätebäume im Kernelbaum https: / / www.kernel / doc / html / aktuell / devicetree /. Für den historischen Kontext, warum Fehler bei Bootloadern gefährlich sind, bieten BootHoles Forschung und Analyse einen guten Hinweis: https: / / www.eclypsium.com / blog / 2020 / boot-hole /.

Kurz gesagt, diese sechs Versagen weisen wiederum auf eine Grundregel hin: die Sicherheit des Bootes ist so stark wie seine schwächste Verbindung in der Vorzeichenphase. Lieferanten, Integratoren und Administratoren müssen bereits handeln, um die vorgelagerten Korrekturen anzuwenden, die Firmware-Vertriebswarnung einschalten und die Art, wie ein bösartiges Bild den Boot-Prozess erreichen könnte reduzieren.