Kritiek lek in UEFI-serverfirmware maakt codeuitvoering mogelijk bij netwerkboot

Door een kritieke kwetsbaarheid in de UEFI-firmware EDK II kunnen kwaadwillenden eigen code uitvoeren op systemen die vanaf het netwerk opstarten. Aanvallers kunnen zonder authenticatie code uitvoeren voordat de beveiligingsfunctie Secure Boot en het OS zelf starten.

De kwetsbaarheid (CVE-2026-97631) in de opensourcefirmware krijgt het cijfer 9.5 op de tienpuntsschaal van het Common Vulnerability Scoring System (CVSS). De EFI Development Kit II (EDK II) wordt gebruikt op het gros van de servers wereldwijd, schrijft Ars Technica. De kwetsbaarheid raakt dus veel computers in datacenters, waaronder ook opslagsystemen. Onder meer Linux-leveranciers Red Hat en Debian waarschuwen voor deze kritieke kwetsbaarheid.

Fix in aantocht

Een patch is nog niet beschikbaar, maar er is al wel een fix ontwikkeld die nog moet worden doorgevoerd in de code van EDK II. De kwetsbaarheid is vorige week al onthuld door TianoCore. Die ontwikkelgemeenschap ondersteunt de open source implementatie van de Unified Extensible Firmware Interface (UEFI) EDK II. Op GitHub legt TianoCore uit hoe de kwetsbaarheid in elkaar steekt.

Een aanvaller moet op een netwerk ICMP-foutberichten (Internet Control Message Protocol) kunnen sturen. Via multicast zijn daarmee meerdere servers op dat netwerk te bereiken. Systemen die via het netwerk opstarten zijn dan vatbaar voor misbruik van de kwetsbaarheid.

Een driver in de opensourcefirmware kopieert de via IPv4 en IPv6 binnenkomende ICMP-foutmeldingen, maar begrenst de opslag van die berichten niet. Dit kan tot een geheugenoverflow leiden. Een aanvaller kan daarna eigen code draaien in het geheugen van kwetsbare servers of een denial-of-serviceaanval uitvoeren.

Uitschakeling van pxe-boot of segmentering van netwerken kan misbruik van de kwetsbaarheid voorkomen. Deze maatregelen kunnen echter impact hebben op het functioneren van servers, datacenters en daar draaiende diensten.

Wachten op serverfabrikanten

Onderzoekers van Anthropic en Google hebben de kritieke kwetsbaarheid in de serverfirmware gevonden. Zij hebben TianoCore ook een aanbevolen fix aangereikt. Moederbordproducenten en serverfabrikanten moeten die oplossing in hun firmware verwerken en de bijgewerkte versie dan uitbrengen voor gebruikers. Het is niet bekend op welke termijn dit gebeurt.

Servers in een datacenter. Bron: Jason Marz/Moment/Getty Images

Reacties (15)

[synoniem]

Dan gaat de CVE er vanuit dat je ICMP buiten het netwerksegment van de betreffende servers toestaat. Lijkt mij geen wenselijke situatie en als ze al binnen je netwerksegment zitten waar vanaf je servers booten ben je in elk geval te laat.

[grasmanek94]

IPv6 vereist werkende ICMP.. anders kan IPv6 niet optimaal werken, of soms helemaal niet, voor zover ik weet dan. Misschien vergis ik mij.

[Reactie gewijzigd door grasmanek94 op 28 oktober 2026 12:59]

[naaitsab]

Lijkt me vrij beperkt dat IPv6 gebruikt wordt in deze interfaces. PXE staat, als het überhaupt al aanstaat, bij een goed ingericht systeem enkel op een 'management' poort aan. Zolang het aantal van deze interfaces niet zowel de A, B als C klassen van het private IPv4 blok (10.x, 172.x en 192.x) vol krijgen, wat praktisch onmogelijk is. Zal het overgrote deel kiezen voor de eenvoud van IPv4 boven IPv6 op dit soort poorten.

Daarbuiten ligt ICMP bij IPv6 wel een stuk genuanceerder, zoals Zepman ook al naar refereert.

[Dreamvoid]

Dat hangt er van af, als je deze machines op oude infrastructuur draait (zoals er nog veel is) dan zullen ze nog wel IPv4 hebben, maar als je een nieuw netwerk bouwt is dat tegenwoordig vaak IPv6-only. Maar ICMP zijn enkel een paar message types, een firewall blokt de rest.

[Reactie gewijzigd door Dreamvoid op 28 oktober 2026 15:32]

[Dreamvoid]

Dat zijn enkel specifieke ICMP messages, zie RFC 4890. Elke firewall filtert de rest eruit.

[GertMenkel]

Als je dedicated servers huurt, zit je hier al aan. Veel partijen die dedicated servers verhuren hebben wel een firewall, maar ik zou er niet van uit gaan dat die je standaard beschermt. Als die firewall er wel is, kun je dat wel gebruiken als mitigatie tot de moederbordfabrikant daadwerkelijk updates verspreidt.

edit:
Overigens is het heel normaal dat je ICMP binnenlaat, tenzij je server achter NAT staat of zoiets. Netwerkproblemen traceren wordt een stuk makkelijker als je ICMP door laat lopen tot het IP dat daadwerkelijk antwoordt, en voor IPv6 hoort ICMP er ook gewoon bij, daar is ICMP filteren vragen om problemen.

[Reactie gewijzigd door GertMenkel op 28 oktober 2026 12:22]

[The Zep Man]

en voor IPv6 hoort ICMP er ook gewoon bij, daar is ICMP filteren vragen om problemen.

Dat is een te brede stelling. De aanbeveling is om sommige berichten niet toe te staan, tenzij er expliciete redenen te bedenken zijn om ze wel toe te staan.

Hier wat meer informatie over de belangrijkste ICMP-berichten.

[Reactie gewijzigd door The Zep Man op 28 oktober 2026 14:53]

[Dreamvoid]

Zie RFC 4890, je moet maar enkele specifieke ICMP berichttypes doorlaten, vrijwel all firewalls blokkeren de rest.

[Stetsed]

"Via multicast zijn daarmee meerdere servers op dat netwerk te bereiken."

Ik weet niet waar tweakers dit vandaan haalt, ja je kan technisch gezien meerdere servers bereieken maar multicast is bijna altijd alleen maar lokaal op groot schaal tenzij je het forward. De writeup zegt expliciet:
"The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP"

Dus ik denk dat het even duidelijk moet worden gezegt dat dit dus niet alleen een probleem met mogelijke multicast berichten is, zoals ik origineel dacht toen ik deze post las. Maar met elk situatie waar een ICMP bericht kan worden verstuurt naar een omgeving die PXE zit te booten.

En dit is natuurlijk veel gevaarlijker, natuurlijk moet PXE eigenlijk geen publieke connectie hebben en alleen een lokale isolated LAN hebben. Maar je hebt well devices die er over booten vanaf een afstand.

Maar zeker met IPv6 wordt ICMP steeds meer gebruikt voor dingen tussen netwerken. En voor de mensen die gellukig nooit problemen hebben gehadt met PMTUD wat ook ICMP gebruikt.. gellukig. Maar het betekent dat ICMP steeds vaker gewoon well is toegestaan.

Wat ik ook well moet zeggen, het KAN tot RCE resulteren, maar zoals wordt gezegt moet je hiervoor weten welke firmware build de device precies draait. Zonder dit kan je nog steeds schade doen door boot te voorkomen

[Reactie gewijzigd door Stetsed op 28 oktober 2026 12:44]

[Keypunchie]

En dit is natuurlijk veel gevaarlijker, natuurlijk moet PXE eigenlijk geen publieke connectie hebben en alleen een lokale isolated LAN hebben. Maar je hebt well devices die er over booten vanaf een afstand.

Lekker handig toch, PXE-booten over het internet!?

Eerlijk gezegd lijken die use cases me klein (alhoewel, als je een organisatie hebt die wereldwijd terminals heeft, ik denk aan bvb. een vliegtuigmaatschappij, dan kan ik me de voordelen wel voorstellen.)

Als het al mogelijk is dan is het eerder misconfiguratie, maar PXE-booten is iets dat je vooral doet wanneer je een uitgebreid fysiek serverpark hebt, dat hebben tegenwoordig gelukkig vooral de echt professionele partijen, die aan iedereen anders leveren.

En daar hoop ik dat netwerksegmentatie toch wel echt een beetje chic is ingericht en dat het niet gewoon via front-end NICs loopt.

[Reactie gewijzigd door Keypunchie op 28 oktober 2026 13:15]

[The Zep Man]

Lekker handig toch, PXE-booten over het internet!?

iPXE heeft bijvoorbeeld ondersteuning voor HTTPS en de EFI binary kan ondertekend zijn voor Secure Boot. Dat is alleen niet handig om je boot mee te initiëren omdat UEFI normaliter geen TLS en HTTP ondersteunt (hooguit TFTP). Je zou wel iPXE lokaal kunnen draaien vanaf (en actueel kunnen houden in) bijvoorbeeld flash.

[Reactie gewijzigd door The Zep Man op 28 oktober 2026 13:28]

[rlKoekie]

Dit kan een flink probleem zijn voor dedicated hosting partijen (Hetzner bijvoorbeeld), waar je een complete machine huurt. In dit soort omgevingen is het normaal om te PXE booten naar een rescue/setup environment, van waaruit je de eerste installatie van je server kan regelen. Dit netwerk boot proces loopt meestal over dezelfde fysieke verbinding als waarmee de machine ook aan het WWW hangt.
De specialisten daar zullen even flink diep de netwerk&firewall configs in moeten, maar waarschijnlijk zullen er wel al wat beschermingen in plaats zijn. Tijdens het PXE netwerk boot proces wil je de machine toch al zo veel mogelijk isoleren om de volle controle te hebben over waar het boot image vandaan komt.

Als je zelf met PXE boot werkt zal dat waarschijnlijk in een behoorlijk geisoleerde setting zijn. Voor een HPC cluster bijvoorbeeld gebruik je PXE boot voor de compute nodes, en deze zijn in principe niet direct verbonden met de buitenwereld.

[kdekker]

Het lijkt me dat PXE boot voor (productie) servers een bijzonder iets is en al helemaal een PXE server buiten je eigen lokale netwerk. Dat brengt m.i. heel wat nuances aan op het woord kritiek uit de titel. Die keren dat ik PXE gebruikt(e) is voor initiele setup (boot recovery, nieuwe image). Dat kan systeembeheer ook prima op haar eigen lokale netwerkje doen. Pas nadat een image op een server draait heb je updates nodig, waarvoor wellicht een publieke verbinding nodig is (en dan heb je PXE als het goed is weer uitgezet in je BIOS).

[dasiro]

Ik probeer me scenario's voor te stellen waarin je servers persistent laat PXE-booten nadat ze zijn ingericht. Dat is imho net een van de dingen die je disabled en uit je bootlist haalt omdat het zo'n gapende attack vector is, zelfs zonder vulnerabilities als deze

[lenwar]

Stateless machines die bij iedere boot een nieuw image krijgen. Denk aan kassaterminals van een supermarkt of iets in die strekking.

"Vroeger" gebruikte Dreamworks kantoor PC's als extra rekenkracht voor het renderen van hun animatiefilms (onder het kopje van 'We hebben gigantisch veel rekenkracht ter beschikking op de kantoren, dat 's nachts helemaal niets doet.) Ik had daar ooit een presentatie van gezien. Die PC's werden na kantoortijden geboot, kregen ze een dedicated mini-OS met rendersoftware erop, en 's ochtends vroeg kregen de PC's weer een 'regulier' besturingssysteem.

Ik heb ooit bij IBM gewerkt en één van de klanten had dit ook voor de PC's. Bij iedere reboot kregen ze een nieuw image.

Dit zijn natuurlijk geen 'servers' in de klassieke zin, maar dit zijn zomaar dingen die ik me 123 kan bedenken.

Maar verder kan ik denken aan compute/renderfarms. Dus in plaats van 'de overhead' van een virtualisatielaag (ongeacht hoe klein die is), kun je zo kinderlijk simpel je servers van een nieuw OS-image voorzien.

Stateless is het devies in deze