Technisch handelt es sich um einen Pufferüberlauf im Netzwerk-Boot-Code von EDK II, bekannt als PXE. Beim PXE-Start lädt ein Rechner sein Startabbild aus dem Netz statt von einer lokalen Platte. Der PXE-Treiber lauscht dabei auf ICMP-Fehlermeldungen und die kurzen Statusnachrichten, die Netzwerkgeräte zurücksenden, und kopiert jede davon in einen festen Speicherbereich von 504 Byte. Die Größenprüfungen in dieser Kopierroutine sind sowohl in der IPv4- als auch in der IPv6-Variante fehlerhaft: Eine Nachricht von mehr als 504 Byte läuft über den Bereich hinaus und überschreibt benachbarten Speicher mit vom Angreifer gewählten Daten.

Zum Auslösen genügt eine einzige präparierte Fehlermeldung an die Adresse der Maschine, während diese gerade über das Netz startet. Ein Passwort oder bestehender Zugang zum System ist nicht nötig – wohl aber Netzwerkreichweite im kurzen Zeitfenster des Bootvorgangs. Red Hat und SUSE, die den betroffenen Code beide ausliefern, stufen die Lücke als aus benachbarter Netzwerkposition ausnutzbar ein, nicht über das offene Internet.

Die einfachste Folge ist ein Absturz: Der Startvorgang hängt, die Maschine fährt nicht hoch. Codeausführung ist deutlich schwieriger und weit weniger zuverlässig. Nach dem Sicherheitshinweis kann ein Angreifer, der den exakten Firmware-Build kennt, ein „gefälschtes Ereignis" platzieren, das die Firmware dazu bringt, eigenen Code des Angreifers auszuführen – ein Exploit muss also auf einen bestimmten Build zugeschnitten werden. Läuft der Code, geschieht das innerhalb der Firmware, bevor Secure Boot und andere Prüfungen beim Start irgendetwas verifiziert haben. Genau dieser Zeitpunkt macht die Lücke gefährlich. Derart platzierter Code läuft nur einmal und übersteht einen Neustart nicht von selbst; dieser eine Lauf reicht aber aus, um anderen Code zu installieren, der bei jedem Start aktiv wird.

Betroffene Versionen und Produkte

Der Fehler steckt in EDK II bis einschließlich edk2-stable202608, der neuesten stabilen Version vom 21. August. EDK II ist der Referenzcode, auf dem nahezu jeder UEFI-Firmware-Hersteller aufbaut, darunter die unabhängigen BIOS-Hersteller AMI, Insyde und Phoenix sowie Microsofts gehärteter Fork Project Mu. Die fehlerhafte Kopierschleife ist seit einem Commit vom November 2010 im Code.

PXE-Netzwerkstart ist im Standard-Build von EDK II standardmäßig aktiviert. Privat- und Büronutzer, die ausschließlich von lokalen Datenträgern starten, sind nicht betroffen; betroffen sind Organisationen, deren Maschinen über das Netz booten, vor allem Server und Rechenzentrumsgeräte. Wie viele ausgelieferte Produkte den verwundbaren Code enthalten, ist unbekannt.

Intel erklärte, es sei bei keinem seiner „derzeit sicherheitsunterstützten kommerziellen Produkte" eine Betroffenheit bekannt; das Unternehmen binde „die betroffene EDK2-Funktionalität nicht in seinen Referenzcode" ein – ein OEM-Board- oder Systemhersteller könne sie allerdings ergänzen. Arm erklärte, die Lücke sei „nicht direkt auf Arms Produktportfolio anwendbar". Die Firmware beider Unternehmen stützt sich auf EDK II.

Auch Linux-Distributionen liefern den Code aus. Red Hat führt sein edk2-Paket in Red Hat Enterprise Linux 8, 9 und 10 als betroffen und noch nicht behoben; SUSE und Debian kennzeichnen ihre entsprechenden Pakete ebenso. AMD, Phoenix Technologies, AMI, Microsoft und Amazon beantworteten gestellte Fragen vor Veröffentlichung nicht, ebenso wenig TianoCore, sodass der Status ihrer Produkte unklar bleibt.

Stand der Korrektur

Ein Fix ist in den Quellcode von EDK II eingeflossen und erreichte am 15. Oktober den Hauptentwicklungszweig. Er schreibt die fehlerhafte Kopierroutine so um, dass eine übergroße Nachricht bei 504 Byte abgeschnitten wird, statt überzulaufen. Kein stabiles EDK-II-Release enthält diesen Fix bislang: Die neueste Release-Markierung, edk2-stable202608, liegt zeitlich davor, und der Sicherheitshinweis führt als gepatchte Version weiterhin „derzeit nicht gepatcht". Microsofts Project Mu hat den Fix bereits in seine Release-Zweige übernommen und am 26. Oktober markierte Builds erstellt.

Auch mit öffentlich verfügbarem Quellcode-Fix hat ein Serverbetreiber nichts zu installieren, solange der Firmware-Hersteller kein darauf aufbauendes BIOS- oder UEFI-Update ausliefert. Dieser Schritt sei immerhin unkompliziert, sagte Jesse Michael, Principal Researcher bei der Firmware-Sicherheitsfirma Eclypsium: Anders als bei Secure-Boot-Umgehungen wie BootHole und BlackLotus lasse sich die Lücke „mit einer einfachen Codekorrektur beheben", Zertifikats- oder Schlüsselwiderrufe seien nicht nötig.

Bis dahin nennt der Sicherheitshinweis keinen Workaround. Da die Lücke nur während eines Netzwerkstarts erreichbar ist, können Betreiber, die PXE nicht benötigen, es abschalten, um die Angriffsfläche zu verringern. Empfohlen wird zudem, den Netzwerkverkehr und die Protokolle während des Bootvorgangs auf Anzeichen entsprechender Versuche zu beobachten.

Wie die Lücke öffentlich wurde

Gefunden wurde der Fehler laut Danksagung im Sicherheitshinweis von Alex Matrosov (Anthropic) und Dan Holmes-Mitra (Google). Geplant war eine koordinierte Offenlegung für Januar 2027. Dieser Plan wurde am 28. September hinfällig, als ein von einem AMI-Ingenieur abgezeichneter Pull Request an EDK II die Lücke öffentlich unter ihrer CVE-Nummer beschrieb und den Fix enthielt. Nachdem die Entdecker den Beitrag bemerkt hatten, veröffentlichte TianoCore seinen Hinweis am 22. Oktober – Wochen vor dem geplanten Termin. Mit dem öffentlichen Patch können versierte Angreifer nun nachvollziehen, wie sich die Lücke auslösen lässt, und funktionierende Exploits bauen.

Hinweise auf eine Ausnutzung in Angriffen gibt es nicht. In CISAs Katalog bekannter ausgenutzter Schwachstellen war die Lücke mit dem Stand vom 27. Oktober nicht enthalten, und kein Forscher hat bislang Ausnutzung beobachtet.

Für sich genommen ist die Schwachstelle auch kein Einstiegsweg in ein Netzwerk; Firmware-Forscher sehen als realistischen Angreifer einen Insider oder jemanden, der bereits einen einfachen Zugang im lokalen Netz erlangt hat und tiefer vordringen will. „Ein Angreifer, der einen nahegelegenen Endpunkt oder Server kompromittieren will, könnte diesen Fehler nutzen, um den Programmfluss an einem Punkt zu kapern, an dem der Bootvorgang noch Zugriff auf sensible Komponenten hat, etwa das TPM des Endpunkts", sagte HD Moore, Schöpfer von Metasploit und Chief Research Officer bei der Sicherheitsfirma Dragos. „Das ließe sich nutzen, um die Festplattenverschlüsselung zu brechen, wenn ein Angreifer kurzzeitigen Netzwerkzugang hat – und im Diebstahlszenario wäre es sogar noch einfacher."

Es ist nicht die erste schwere Lücke im Netzwerk-Boot-Code von EDK II: Im Januar 2024 legten Forscher PixieFail offen, eine Reihe von neun Schwachstellen in demselben Codeteil, ebenfalls während des PXE-Starts erreichbar. Fuzzing-Projekte, die nach PixieFail gestartet wurden, um weitere Fehler in diesem Code zu finden, haben diesen Fehler nicht entdeckt.