28. Oktober 2026TianoCore · SicherheitKuratiert

PXE-Boot als Einfallstor: Pufferüberlauf in EDK II trifft Server-Firmware vor Secure Boot

Zusammenfassung

Das TianoCore-Projekt beschreibt im Sicherheitshinweis GHSA-99cj-7hg9-mp4m einen Pufferüberlauf im PXE-Treiber von EDK II, den Alex Matrosov (Anthropic) und Dan Holmes-Mitra (Google) gefunden haben. Eine präparierte ICMP-Fehlermeldung während des Netzwerkstarts kann Code in der Firmware ausführen, bevor Secure Boot oder Measured Boot irgendetwas geprüft haben. Weil ein öffentlicher Pull Request das Embargo Monate zu früh gebrochen hat, liegt die Korrektur im Quelltext vor, während offen ist, wann die Hersteller Firmware-Updates liefern.

Was im Treiber schiefgeht

EDK II ist die quelloffene Referenzimplementierung von UEFI. Firmware-Hersteller wie AMI, Insyde und Phoenix bauen ihre Firmware darauf auf, ebenso Microsofts Fork Project Mu und die Firmware OVMF für virtuelle Maschinen. Der betroffene Treiber NetworkPkg/UefiPxeBcDxe erledigt den Netzwerkstart per PXE über IPv4 und IPv6.

Solange ein Rechner per PXE startet, hält der Treiber eine Empfangsanforderung für ICMP-Fehlermeldungen offen und kopiert jede empfangene Meldung in das Feld Mode.IcmpError, das genau 504 Byte groß ist. Die Kopierschleife in beiden Handlern (PxeBcIcmpErrorDpcHandle für IPv4, PxeBcIcmp6ErrorDpcHandle für IPv6) prüft die Grenzen falsch: Eine längere Meldung wird trotzdem kopiert, und der Zielzeiger rückt um die aufsummierte statt um die Länge des einzelnen Fragments vor. So landen Bytes des Angreifers hinter dem Feld. Vorher begrenzt nichts auf dem Empfangsweg die Länge der Meldung.

Die Korrektur prüft die Grenzen, rechnet die Versätze richtig, kürzt zu lange Meldungen und leert den Puffer vor jedem Kopieren. Dazu kamen Unit-Tests, die vor der Änderung scheitern und danach durchlaufen.

Was ein Angreifer damit erreicht

Laut Advisory gibt es zwei Stufen. Sicher erreichbar ist ein Absturz: Die nächste ICMP-Fehlermeldung beschädigt die Daten des Treibers, eine CPU-Ausnahme im DXE-Kern lässt den Start hängen, und der Rechner lässt sich weder installieren noch wiederherstellen. Kennt der Angreifer den genauen Firmware-Stand, kann er im selben Paket ein gefälschtes Ereignis unterbringen, das CoreSignalEvent() ausführt. Der Code läuft dann in Ring 0 der DXE-Phase, bevor irgendeine Schutzfunktion des Betriebssystems existiert.

Ars Technica ordnet ein: Die Schadfunktion überdauert keinen Neustart, kann aber in dieser Zeit weitere Komponenten einrichten, die bei jedem Start früh laufen. HD Moore (Dragos) weist darauf hin, dass die Firmware zu diesem Zeitpunkt noch Zugriff auf das TPM hat; das kann Festplattenverschlüsselung aushebeln, die sich auf das TPM verlässt, schon bei kurzem Netzzugang und noch leichter bei einem gestohlenen Gerät. Laut Ars umgehen solche Exploits auch die Attestierung, mit der ein Server einem entfernten Dienst kryptografisch belegen soll, dass seine Hardware unverändert ist. Jesse Michael (Eclypsium) bremst: Ein Exploit muss Adressen im Zielsystem kennen und deshalb für jedes Modell, jede Version und jede Konfiguration angepasst werden.

Als ersten Schritt in ein fremdes Netz taugt die Lücke nach bisherigem Stand nicht: Ars sieht dafür keinen Hinweis. Wahrscheinliche Nutzer sind Innentäter oder Angreifer, die bereits im Netz stehen, etwa staatliche Gruppen oder Ransomware-Banden, die ihre Rechte ausweiten wollen.

Wer betroffen ist

Angreifbar ist nur ein Rechner, der gerade per PXE startet, und nur für die Dauer dieses Starts. Wer von SSD oder Festplatte startet, ist von dieser Lücke nicht betroffen. Laut Ars Technica ist PXE in EDK-II-basierter Firmware aber standardmäßig eingeschaltet, und in Rechenzentren ist der Netzwerkstart für Installation und Wiederherstellung verbreitet.

Intel teilte Ars mit, keine derzeit unterstützten kommerziellen Produkte seien bekanntermaßen betroffen, Hersteller von Mainboards könnten den Code aber selbst eingebaut haben. Arm nennt die Lücke für sein Portfolio „nicht direkt anwendbar“. AMD, AMI, Phoenix, Microsoft und Amazon antworteten bis zur Veröffentlichung nicht. Debian führt das Paket edk2, aus dem OVMF stammt, am 28. Oktober in bookworm, trixie und sid als verwundbar.

Einordnung: die nächste Firmware-Lücke vor dem Betriebssystem

Ars Technica stellt die Lücke in eine Reihe mit LogoFail (Fehler beim Darstellen der Herstellerlogos in der Firmware), PKFail (Test-Plattformschlüssel, die über ein Jahrzehnt öffentlich waren und in Hunderten Gerätemodellen steckten), BootHole und dem Bootkit BlackLotus. Am nächsten verwandt ist PixieFail: Quarkslab beschrieb im Januar 2024 neun Schwachstellen im IPv6-Netzwerkstack von EDK II, der ebenfalls beim PXE-Start arbeitet.

Ein Unterschied erleichtert die Abhilfe. Jesse Michael (Eclypsium) betont, dass anders als bei BootHole, BlackLotus oder Baton Drop keine Sperrlisten, kein Austausch von PK-, KEK-, db- oder dbx-Einträgen und keine neuen Boot- oder Installationsmedien nötig sind; ein BIOS- bzw. UEFI-Update genügt. HD Moore erwartet trotzdem einen „forever bug“, der in Systemen ohne Herstellersupport dauerhaft bleibt.

Wie das Embargo brach

Die Finder hatten eine koordinierte Veröffentlichung für Januar 2027 vereinbart. Am 28. September 2026 reichte ein Entwickler von AMI die Korrektur jedoch als öffentlichen Pull Request #13200 ein, mit Beschreibung der Ursache und der CVE-Nummer im Titel. Michael Kinney (Intel) überarbeitete ihn als #13302, der am 15. Oktober in den master-Zweig einging. Das Advisory folgte am 22. Oktober. Golem nennt als Grund für die frühere Offenlegung, dass Angreifer aus dem öffentlichen Patch heute auch mit KI-Hilfe schnell einen Exploit bauen könnten; dafür genügt der Vergleich von altem und neuem Code.

Am 27. Oktober bestätigte TianoCore im Pull Request, das Embargo sei durch einen Fehler gebrochen worden. Im selben Verlauf beklagt ein anderer Melder, dass private Sicherheitsmeldungen seit Monaten unbeantwortet blieben, während öffentliche Pull Requests schnell geprüft würden. TianoCore räumt einen Rückstau ein und will Meldungen mit fertigem Patch vorziehen.

Selbst prüfen: Linux, Proxmox, libvirt

Auf einem Linux-Rechner mit UEFI zeigt efibootmgr -v die Starteinträge im NVRAM. Netzwerkstart erkennt man an Einträgen wie „UEFI PXEv4“ oder „PXEv6“ bzw. an Gerätepfaden mit MAC(…)/IPv4(…) oder IPv6(…). Fehlt ein solcher Eintrag, kann die Firmware den Netzwerkstack trotzdem über eine Setup-Option aktiv haben; das lässt sich nur im Setup oder über iLO, iDRAC bzw. Redfish prüfen.

dmidecode -s bios-vendor und dmidecode -s bios-version nennen Firmware-Zulieferer und Stand. AMI, Insyde oder Phoenix deuten auf EDK-II-Code hin, belegen ihn aber nicht; Intel weist darauf hin, dass Board-Hersteller den Treiber selbst einbauen können. Verbindlich ist nur die Antwort des Herstellers.

Auf Proxmox zeigt qm config <vmid> | grep -E '^(bios|boot)', ob eine VM mit bios: ovmf läuft und net0 in der Startreihenfolge steht. Betroffen sein kann nur diese Kombination, denn den Netzwerkstack von EDK II bringt nur OVMF mit; VMs mit SeaBIOS starten per iPXE und sind von dieser Lücke nicht betroffen. Die Firmware liefert Proxmox im Paket pve-edk2-firmware. Unter libvirt verrät virsh dumpxml <vm> den Loader (OVMF) und ein <boot dev='network'/> bzw. ein boot order am Netzwerkgerät.

Ideen

Ein Fehler vor dem Betriebssystem umgeht Secure Boot, weil noch nichts geprüft wurde.
Der PXE-Treiber nimmt während des Netzwerkstarts ICMP-Fehlermeldungen ohne Authentifizierung an.
Nur Rechner, die gerade per PXE starten, sind angreifbar; Start von SSD nicht.
Ein Exploit muss an Modell, Firmware-Stand und Konfiguration angepasst werden.
Die Korrektur braucht nur ein Firmware-Update, keine Sperrlisten für Secure Boot.
Ein versehentlich öffentlicher Pull Request kann ein Embargo um Monate verkürzen.
Auch virtuelle Maschinen mit OVMF bringen den Netzwerkstack von EDK II mit.

Einsichten

Wenn fast alle Firmware-Hersteller denselben Referenzcode nutzen, wird ein Fehler darin zum Problem einer ganzen Branche. Wie schnell er verschwindet, bestimmt der langsamste Hersteller; Server ohne Support bleiben dauerhaft verwundbar.
Secure Boot und Measured Boot schützen nur, was nach ihnen geladen wird. Der Netzwerkstack der Firmware selbst liegt davor; schon PixieFail traf 2024 denselben Bereich von EDK II, und die anschließenden Fuzzing-Kampagnen fanden diesen Fehler nicht.
Wenn öffentliche Pull Requests schneller geprüft werden als vertrauliche Meldungen, belohnt ein Projekt genau den Weg, der koordinierte Veröffentlichung unterläuft.

Zitate

„The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance; the exposure window is the duration of the PXE boot.“ (TianoCore-Advisory GHSA-99cj-7hg9-mp4m; sinngemäß: Der Angreifer muss nur eine Unicast-ICMP-Fehlermeldung an die IP-Adresse des Clients schicken, aus beliebiger Netzentfernung; angreifbar ist der Rechner für die Dauer des PXE-Starts.)
„In this particular GHSA example, embargo was violated due to a mistake, resulting in the PR being created in the open.“ (TianoCore im Pull Request #13302 am 27. Oktober 2026; sinngemäß: In diesem Fall wurde das Embargo durch einen Fehler gebrochen, deshalb entstand der Pull Request öffentlich.)

Fakten

CVE-2026-97631 hat nach CVSS v4 die Bewertung 9,5 (kritisch); das Advisory erschien am 22. Oktober 2026.
Betroffen ist NetworkPkg/UefiPxeBcDxe; das Feld Mode.IcmpError ist 504 Byte groß, IPv4 und IPv6 sind betroffen.
Der öffentliche Pull Request #13200 stammt vom 28. September 2026, die Korrektur (#13302) ging am 15. Oktober in master ein.
Debian führt edk2 am 28. Oktober 2026 in bookworm, trixie und sid als verwundbar (Debian-Bug 1151853).
Laut Ars Technica war die koordinierte Veröffentlichung für Januar 2027 geplant.

Referenzen

Kritik

Golem, heise, Dr. Web und Ars Technica schreiben, der Angreifer brauche Zugang zum lokalen Netz. Das Advisory nennt dagegen eine Unicast-Meldung „from any network distance“. Entscheidend ist, ob die Adresse des startenden Rechners erreichbar ist; die Beschränkung aufs LAN beschreibt typische Netze, nicht die Lücke selbst.
Das Advisory führt unter „Patched versions“ am 28. Oktober weiter „Not patched currently“, obwohl die Korrektur seit dem 15. Oktober im master-Zweig liegt. Wer nur das Advisory liest, schätzt den Stand falsch ein.

Bemerkungen

Die Angabe „16 Jahre“ stammt von Ars Technica, Golem und heise übernehmen sie; Advisory und Pull Requests nennen kein Alter des Fehlers. heise (nach t3n) datiert die öffentliche Korrektur auf Mitte Oktober; öffentlich war Pull Request #13200 schon am 28. September, Mitte Oktober folgte nur die Übernahme in master.
Debian stuft die Lücke für trixie als „Minor issue“ ohne eigenes Sicherheitsupdate ein; OVMF-Nutzer warten also auf ein reguläres Paketupdate.

Empfehlungen

Bestand erheben: Unter Linux zeigt efibootmgr -v, ob PXE-Einträge für IPv4 oder IPv6 in der Startreihenfolge stehen; bei Servern zusätzlich über iLO, iDRAC oder Redfish prüfen.
Netzwerkstart abschalten oder aus der Startreihenfolge nehmen, wo er nicht gebraucht wird; nötige PXE-Installationen in ein eigenes Bereitstellungsnetz legen, in das Arbeitsplatzrechner und Geräte im Gästenetz keine Pakete schicken können und das ICMP-Fehlermeldungen von außen nicht erreichen.
Beim Hersteller von Server oder Mainboard nach einem Firmware-Update für CVE-2026-97631 fragen, Mieter dedizierter Server beim Hoster nach dem Termin. Geräte ohne Support als dauerhaft verwundbar führen und aus dem Bootnetz nehmen, bevor ein Exploit für ihr Modell existiert; Einrichtungen unter NIS2 führen die Lücke im Schwachstellenmanagement nach § 30 BSIG.
Auf Proxmox oder libvirt prüfen, welche VMs mit OVMF per Netzwerk starten, und das edk2- bzw. OVMF-Paket aktualisieren, sobald die Distribution es korrigiert.

Sicherheitshinweis lesen

Im Webarchiv suchen