UEFI-lek EDK II: code vóór Secure Boot via PXE-boot

Onderzoekers van Anthropic en Google hebben een kritieke kwetsbaarheid gevonden in EDK II, de opensource-referentiecode waarop vrijwel alle UEFI-firmware voor servers is gebouwd. Een aanvaller die tijdens een netwerkboot één ICMP-foutbericht kan afleveren, voert code uit voordat Secure Boot ook maar iets heeft gecontroleerd. TianoCore publiceerde op 22 oktober het advies.

Een veld van 504 bytes dat overloopt

Het lek, CVE-2026-97631, zit in de PXE Base Code-driver NetworkPkg/UefiPxeBcDxe en is volgens Ars Technica een buffer overflow die er zestien jaar in heeft gezeten. De driver houdt tijdens het opstarten via het netwerk een ontvangstverzoek open voor ICMP-foutmeldingen en kopieert elk bericht naar een vast veld van 504 bytes, Mode.IcmpError. In zowel de IPv4- als de IPv6-handler (PxeBcIcmpErrorDpcHandle en PxeBcIcmp6ErrorDpcHandle) is de grenscontrole van die kopieerlus fout. Bij een bericht langer dan 504 bytes kopieert de driver door, en hij verschuift de bestemmingspointer met de cumulatieve lengte in plaats van die van het losse fragment. Nergens eerder in het ontvangstpad wordt de lengte begrensd.

Het resultaat is geheugencorruptie in de DXE-fase van de firmware. In het beste geval loopt de boot vast: een denial of service op precies het proces waarmee je machines uitrolt of herstelt. Weet een aanvaller welke firmwarebuild er draait, dan kan hij volgens het advies in hetzelfde pakket een vals event planten dat via CoreSignalEvent() zijn eigen bytes laat uitvoeren — in ring 0, voordat er één OS-beveiliging bestaat.

TianoCore geeft de bug een CVSS 4.0-score van 9,5. Red Hat houdt het op 8,8 volgens CVSS 3.1, met als belangrijk verschil dat Red Hat uitgaat van een aanvaller op hetzelfde netwerksegment.

De openbaarmaking liep uit de hand

Alex Matrosov (Anthropic) en Dan Holmes-Mitra (Google) deden de vondst. Zij hadden met TianoCore een gecoördineerde openbaarmaking in januari afgesproken, schrijft Ars Technica. Die planning sneuvelde toen moederbordfabrikant AMI vorige maand een pull request publiceerde waarin de kwetsbaarheid én de codefix beschreven stonden. Daarop bracht TianoCore het advies alsnog naar buiten.

Gevolg: de patchcode is openbaar, de firmware-updates zijn dat nog niet. De fix zit inmiddels wel in de master van EDK II, via pull request 13302. Daarachter loopt de hele keten nog: Debian markeert zijn edk2-pakketten in bookworm, trixie en sid nog als kwetsbaar, Red Hat zet RHEL 8, 9 en 10 op "Affected" zonder fix, en daarna moeten bordenbouwers en serverfabrikanten de code nog in hun eigen firmware verwerken.

Volgens Ars gebruiken vrijwel alle firmwareleveranciers EDK II, waaronder AMI, Insyde en Phoenix; ook Project Mu, de gehardende fork van Microsoft, bevat het kwetsbare onderdeel. Intel en Arm laten aan Ars weten dat hun eigen producten voor zover bekend niet geraakt worden, maar Ars tekent aan dat een OEM de betrokken code er alsnog in kan hebben gezet.

Wat je nu kunt doen

• Bepaal eerst of je netwerkboot gebruikt. Alleen machines die via PXE opstarten zijn kwetsbaar; wie uitsluitend vanaf schijf boot, loopt volgens Ars geen risico. PXE staat op servers wel standaard aan.
• Zet PXE-boot uit waar je het niet nodig hebt, of segmenteer het netwerk. Dat zijn de twee maatregelen die TianoCore en Ars noemen zolang er geen firmware is. Houd er rekening mee dat beide ingrepen je uitrol- en herstelprocedures kunnen raken.
• Vraag je serverleverancier om een planning. Intel verwijst klanten expliciet naar de systeemfabrikant. Jesse Michael van Eclypsium tekent bij Ars aan dat dit — anders dan bij BootHole of BlackLotus — met een gewone BIOS/UEFI-update te verhelpen is, zonder gedoe met dbx- en sleutelbeheer.
• Onderschat de impact niet. HD Moore van Dragos wijst erop dat een aanvaller met kortdurende netwerktoegang zo bij de TPM kan komen en schijfversleuteling kan breken.