LONDON (IT BOLTWISE) – Security-Forscher zeigen, dass 11 alte, Microsoft-signierte UEFI-Shim-Loader unter bestimmten Bedingungen Secure Boot aushebeln können. Der Schlüssel ist eine weiterhin vertraute Zertifikatskette, obwohl einzelne Komponenten seit 2026 abgelaufen sind. Angreifer können damit schon in der Boot-Phase untrusted Code ausführen und Persistenz aufbauen, bevor Betriebssystem und EDR/AV starten. Microsoft hat die betroffenen Shims inzwischen per Patch-Zyklus zurückgezogen.
Secure Boot soll genau das verhindern, was jetzt wieder in den Fokus gerät: das Laden manipulierten Codes während des Systemstarts. In diesem Fall geht es nicht um eine neue, exotische Schwachstelle im Bootprozess, sondern um die Missbrauchbarkeit alter, noch im Trust-Store der Firmware verankerter Komponenten. Ein Security-Team hat 11 UEFI-Anwendungen identifiziert, die über eine von der Firmware akzeptierte Microsoft-Zertifikatskette als „vertrauenswürdig“ erscheinen. Kritisch ist die Wirkung: Wird eine dieser Shims-Ketten ausgenutzt, kann ein Angreifer untrusted Code unmittelbar beim Booten ausführen und damit Bootkits oder andere Malware einschleusen, auch wenn das Betriebssystem bereits gepatcht ist.
Technisch betrachtet folgt der Startpfad in vielen Linux-Setups dem gleichen Schichtenmodell: Die UEFI-Firmware lädt zunächst den Shim und prüft dessen Signatur anhand des in der Firmware gespeicherten Microsoft-CA-Zertifikats „Microsoft Corporation UEFI CA 2011“. Der Shim ist dabei bewusst leichtgewichtig und fungiert als Vermittler zwischen Mainboard-Firmware und Linux-Bootloader. Anschließend validiert der Shim den zweiten Bootloader—häufig GRUB 2—gegen ein im Shim eingebettetes Zertifikat. GRUB wiederum prüft den Kernel über denselben Mechanismus. Der Bypass entsteht, weil eine ältere Shim-Version weiterhin durch die Trust-Struktur als gültig gilt, selbst wenn andere Schutzmechanismen später greifen müssten.
Der Markt- und Lieferkettenbezug ist damit deutlich: Betroffen sind nicht nur einzelne Open-Source-Komponenten, sondern auch vendor-spezifische Builds, die auf denselben Shim-Interfaces aufsetzen. In der Analyse werden beispielsweise u.a. Red Hat Enterprise Linux 7.2, CentOS 7.2 sowie RO SA Linux (R9/R10) mit konkreten Shim-Versionen genannt; zudem tauchen Produkte aus dem Enterprise-Umfeld auf, darunter ein Management-Setup von Baramundi sowie WipeDrive-Funktionen von WhiteCanyon/Blancco. Zusätzlich werden Shims aus unterschiedlichen Linux-Distributionen und Boot-Umgebungen bis hin zu UEFI Shim loader 0.7/0.8/0.9 adressiert. Das zeigt, wie stark „Secure-by-Default“-Versprechen in der Praxis von Update-Disziplin und Signatur-Revocation-Logik abhängen.
Historisch erklärt sich das Problem aus der Entwicklung des UEFI-Ökosystems: Secure Boot basiert auf einer Signaturprüfung entlang einer Kette, ergänzt durch Mechanismen wie DBX-Revocation-Listen und später SBAT (Secure Boot Advanced Targeting). SBAT soll eher ganze Generationen bzw. Versionen eines Boot-Elements widerrufen, statt riesige Hash-Listen für jede einzelne Datei zu pflegen. Wenn vendor-spezifische Bootloader nach Bekanntwerden upstream-seitig gefixter Schwachstellen nicht aktualisiert werden, bleiben sie unter Umständen signiert und werden nicht über DBX explizit zurückgezogen. Genau darauf verwies zuletzt auch eine CERT-CC-Einschätzung: Vulnerable bootloaders hätten nicht nachgezogen, wodurch „long-term supply chain exposure“ entsteht—selbst auf Systemen, die ansonsten aktuell sind.
Für Angreifer eröffnet die Lücke außerdem zwei besonders unangenehme Wege. Erstens kann das BYOVD-Muster (Bring Your Own Vulnerable Driver) genutzt werden, um während der frühen Bootphase beliebigen Code laufen zu lassen, noch bevor das Betriebssystem und Sicherheitssoftware initialisiert wurden. Zweitens spielt die MOK-Allowlist (Machine Owner Key) hinein: Linux-Systeme nutzen ein Nutzer-gesteuertes Allowlisting, um im Secure-Boot-Kontext auch nicht signierte Treiber nachzuladen. In shim-Version 0.9 wurde zwar eine MOK-Denylist eingeführt, um alte, problematische Signaturketten zu widerrufen und neu zu signieren. Die Analyse zeigt jedoch, wie ein Angreifer versuchen kann, durch das Zurückspielen eines älteren, noch vertrauenswürdigen Shims die Denylist-Logik zu umgehen—so, dass verletzliche Komponenten wieder geladen werden und am Ende ein Arbitrary Code Execution-Ziel erreichbar ist.
Die Auswirkungen gehen über „nur“ einen Bypass hinaus. Wenn Code über den Shim/Bootloader-Kanal ausgeführt wird, kann er zudem eingebaute Erkennungsmechanismen und EDR/Endpoint-Telestrie umgehen, weil EDR-Agenten typischerweise erst nach der OS-Initialisierung greifen. In der Folge sind Persistenz-Strategien möglich, die auch Reboots und in einigen Fällen sogar Betriebssystem-Neuinstallationen überdauern können, solange die Bootkette weiterhin angreifbar bleibt. Verfolgt wird das Thema über CVE-2026-8863 sowie CVE-2026-10797; letzteres bezieht sich auf eine bereits länger gepatchte shim-Thematik zur Umgehung eines Zertifikats-Revocation-Checks durch Modifikation im Signatur-Header. Wichtig ist außerdem die Klarstellung: Das Ablaufdatum des „Microsoft Corporation UEFI CA 2011“-Zertifikats wirkt allein nicht wie ein Schutz, solange betroffene Shims nicht per Hash bzw. passender Revocation-Mechanik gezielt entwertet wurden.
Für die nächste Phase ist entscheidend, wie Unternehmen und Distributionen reagieren. Microsoft hat die relevanten UEFI Shim-Loader inzwischen als Teil seines Patch-Zyklus im Juni 2026 zurückgezogen; dadurch sinkt die Angriffsfläche, aber nur dann, wenn Systeme wirklich die aktualisierten Pakete erhalten und die Revocation-Logik in der Firmware sauber greift. Enterprise-Teams sollten deshalb nicht nur Betriebssystem-Updates, sondern explizit die UEFI-Boot-Kette, Shim- und GRUB-Versionen sowie etwaige vendor-spezifische Boot-Komponenten prüfen. Zusätzlich lohnt sich eine Prozessanpassung für „Software Supply Chain“-Kontrollen: SBAT/DBX-Updates, Paketquellen, Signing-Policies und MOK-Workflows müssen auditierbar sein, da sonst genau diese Art von Reproduzierbarkeit in die falschen Hände gerät. Aus Entwickler- und Admin-Sicht bedeutet das: Boot-Security wird zur Betriebsdisziplin—und mit jedem Update-Fenster wird die Zeitspanne zwischen Patch und Revocation zur kritischen Wettbewerbsvariable.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Veraltete Microsoft-signierte Linux-UEFI-Shims: Secure-Boot-Bypass möglich" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Veraltete Microsoft-signierte Linux-UEFI-Shims: Secure-Boot-Bypass möglich" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Veraltete Microsoft-signierte Linux-UEFI-Shims: Secure-Boot-Bypass möglich« bei Google Deutschland suchen, bei Bing oder Google News!