Bug in UEFI-firmware Phoenix treft meerdere generaties Intel-cpu’s

Cybersecuritybedrijf Eclypsium heeft een beveiligingslek ontdekt in de SecureCore-UEFI-firmware van Phoenix. Een aanvaller kan deze kwetsbaarheid gebruiken om malafide code uit te voeren op bepaalde apparaten met een moderne Intel-processor.

De kwetsbaarheid CVE-2024-0762, ook bekend als UEFIcanhazbufferoverflow, is een bug in de Trusted Platform Module die kan leiden tot een bufferoverflow en het potentieel uitvoeren van schadelijke code. Aangezien de UEFI als communicatielaag tussen de hardware en het besturingssysteem fungeert, is het moeilijk om dergelijke aanvallen te ontwijken en te detecteren. Bovendien zijn firmware-updates nodig om de kwetsbaarheid te dichten.

Eclypsium ontdekte de bug in de Lenovo ThinkPad X1 Carbon 7th Gen en X1 Yoga 4th Gen. Phoenix Technologies heeft bevestigd dat het lek gevolgen heeft voor verschillende Intel-processors, waaronder Alder Lake, Coffee Lake, Comet Lake, Ice Lake, Jasper Lake, Kaby Lake, Meteor Lake, Raptor Lake, Rocket Lake en Tiger Lake. Het gaat om zowel mobiele cpu’s als desktopchips.

Het beveiligingsbedrijf waarschuwt dat potentieel honderden verschillende pc-modellen getroffen kunnen zijn. Verschillende fabrikanten gebruiken namelijk de eerdergenoemde Intel-processors in combinatie met de Phoenix SecureCore-UEFI-firmware. Of een model daadwerkelijk kwetsbaar is, hangt af van de standaard toegewezen configuratie en rechten.

Reacties (34)

[MneoreJ]

Zoals bijna gebruikelijk bij dit soort dingen (zou niet moeten) verbergt men de details van de praktische impact van de kwetsbaarheid enkele paragrafen diep: "the vulnerability allows a local attacker to escalate privileges and gain code execution within the UEFI firmware during runtime", en dit dus door het zetten van een UEFI variabele met een speciale waarde die te lang is. Om dit te kunnen doen (de variabele zetten) moet je administratorrechten hebben, daarna kan iemand zonder rechten door het ophalen van de variabele code laten uitvoeren door de firmware. Met andere woorden, voor je dit kunt uitbuiten moet je al binnen zijn.

Dat betekent natuurlijk niet dat dit onbelangrijk is; kloten met de UEFI kan het bijkans onmogelijk maken zelfs voor administrators om een gecompromitteerde machine te detecteren en te herstellen en zulke dingen moeten zeker gefixt worden. Het betekent alleen dat de praktische impact voor de gemiddelde gebruiker nihil is, aangezien je veel simpelere en effectievere dingen kunt doen als je toch al admin bent. Dit is meer iets voor aanvallers die specifieke machines en configuraties willen uitbuiten (a la staatshackers).

[Reactie gewijzigd door MneoreJ op 23 juli 2024 01:11]

[latka]

Variabele kan gewoon via een windows api gezet worden: https://learn.microsoft.c...areenvironmentvariableexa
Dus een kwestie van een windows exploit en je kunt via de uefi een rootkit onder windows krijgen. Niet triviaal, maar zeker niet gewenst.

[MneoreJ]

Natuurlijk niet gewenst, daarom wordt het ook gepatched. Maar "to write a firmware environment variable, the user account that the app is running under must have the `SE_SYSTEM_ENVIRONMENT_NAME` privilege. A Universal Windows app must be run from an administrator account and follow the requirements outlined in 'Access UEFI firmware variables from a Universal Windows App'." Het is privilege escalation, maar meer van admin naar super-duper-admin met een rootkit.

[latka]

Meer: het lijk niet lokaal te hoeven. Je kunt via het netwerk UEFI zetten en dan wachten op een reboot om je ding te doen. Local access lijkt dan ook niet nodig, maar er zijn nog niet genoeg details bekend om dat met zekerheid te zeggen.

[MneoreJ]

Stel dat: dan nog zal niet iedere boerenkinkel de UEFI kunnen zetten over het netwerk, tenzij er iets grondig mis is gegaan bij het instellen van de beveiliging, want ook zonder buffer overflow kun je daarmee aanzienlijke schade aanrichten. En dan heb je het al over iets als een bedrijfsopstelling waar machines remote beheerd worden. Een kwetsbaarheid als deze kan dan gebruikt worden als je ergens binnen bent op een machine, om dan dieper binnen te dringen in de rest van de systemen. Allemaal eng genoeg dat je als professionele beheerder de boel wel graag gepatched zou zien, maar niet bepaald iets waar je op zondag voor uit je bed gebeld wordt, om het zo te stellen.

[HollowGamer]

Dit gaat over app-toegang, maar daarbuiten kan het gewoon.

Je hebt het hier ook over een UWA/UWP, die zijn beide anders dan een 'normale' applicatie. En dan nog, UEFI is echt ontzettend open. Je zult versteld staan wat je allemaal kan doen ermee in het OS zelf.

[MneoreJ]

De docs beschrijven wat nodig is voor zowel een Win32 app als een UWP. Een gewone Win32 app heeft een specifiek `SE_` privilege nodig. Dat zijn bijzondere rechten die je normaal gesproken niet hebt zelfs als administrator, maar die door een proces met administratorrechten tijdelijk enabled kunnen worden om iets te doen (`AdjustTokenPrivileges`).

Ik weet niet precies wat je bedoelt met "app toegang"; in Windows zijn alle rechten gekoppeld aan het gebruikersaccount. Applicaties kunnen precies wat de gebruiker kan, niet meer en normaal gesproken niet minder (anders dan gewijzigd door laagjes als UAC).

UWP wordt apart genoemd omdat de boel daar net even iets anders werkt en de rechten via het manifest geregeld moeten worden, maar in beide gevallen geldt dat je als unprivileged gebruiker niet gewoon die waardes kunt zetten. Er zijn ongetwijfeld wel opstellingen waar je via-via alsnog als gewone gebruiker dit kunt doen, maar dan middels services of toepassingen die door de admin geïnstalleerd zijn en hier specifiek voor zijn. Voor zover ik weet niet in vanilla Windows.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 01:11]

[HollowGamer]

Wat als ik je laptop 'vind', en via deze weg bij je gegevens kom? Is het dan nog geen probleem?

Het is altijd leuk om te roepen dat men zich niet zo moet druk maken. Maar ik kan mijn laptop/devices ook verliezen, en dan is het minder leuk. Zeker als er interessante dingen op kunnen staan, die worden namelijk meestal gesynced, en niet elk device kan je remote wissen.

Iemand die slim is, kan een Windows een Administrator aanmaken, de TPM uitlezen (zie andere lekken) of via een Linux-distro booten, en dan die UEFI-flag zetten. Is de kans klein? Ja, maar dan nog is het niet 'oh, maak je niet druk'.

Het probleem is dat veel mensen dat niet willen zien. Een lek is nog altijd een lek, of daar nu ducktape overheen zit of niet.

[MneoreJ]

Wat als ik je laptop 'vind', en via deze weg bij je gegevens kom? Is het dan nog geen probleem?

Het lijkt mij dat het een probleem is ongeacht hoe je bij mijn gegevens bent gekomen, maar als je bij mijn gegevens bent gekomen, dan zeer waarschijnlijk niet via deze exploit.

Iemand die slim is, kan een Windows een Administrator aanmaken [...]

De rest van je stappen kunnen we volgens mij weglaten. Als ik jouw laptop heb en het is voor mij blijkbaar al mogelijk om een admin account aan te maken is het game over. Zelfs dingen als user encryptie zijn een beperkt struikelblok omdat ik drivers kan installeren die dat omzeilen. Of ik stel gewoon je wachtwoord opnieuw in, natuurlijk.

Ieder lek is er natuurlijk een teveel en defense in depth betekent dat idealiter ieder lek gepatched wordt, maar niet ieder lek heeft dezelfde impact. We moeten niet alle lekken op een hoop vegen, want dan is het gevaar dat de focus niet komt te liggen op de kritieke dingen die als eerste gepatched moeten worden.

Heb je een kwetsbare laptop, dan natuurlijk vooral patchen, better safe than sorry. Moet iedereen met een UEFI die een processor heeft die in die lange en enge lijst opgesomd wordt bang worden dat de internet haxxors de machine overnemen? Nee, dat ook zeker niet.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 01:11]

[HollowGamer]

Daar heb je wel een punt, snap dat elk lek niet even belangrijk of impact vol is.

Ik ben zelf niet zo'n fan van lekken downplayen. Zeker bij UEFI zie ik het net te vaak, en dat voor een 'simpele' loader die mijn hardware enkel hoeft te laden bij het opstarten (kort gezegd). Ik vind UEFI echt veel te onnodig complex en onveilig. Helaas zijn alternatieven als Libreboot bijna onmogelijk voor de meeste.

[Cerberus_tm]

Goede reacties van jou hier, duidelijk en weldoordacht.

[hbvdh]

Aangezien er een tpm gebruikt wordt zal er ook diskecryptie gebruikt worden, dan is een admin aanmaken wel heeel lastig. Een linux boot zou dan wel deze exploit kunnen gebruiken om de desbetreffende flag aan te zetten malware te injecteren en dan naar windows booten om daar in te loggen en de gegevens te misbruiken.

edit: de malware zou dan de login omzeilen...

[Reactie gewijzigd door hbvdh op 23 juli 2024 01:11]

[Blokker_1999]

Als je mijn laptop vindt, kan je mij dan een seintje geven, regelen we wel om hem terug bij mij te krijgen.

Maar veel plezier ermee zou ik zeggen. Mijn harde schijven zijn encrypted met bitlocker, daar kom je dus al niet in. Je zou dan al de moeite moeten nemen om mijn SSD eruit te halen, een andere erin te steken om dan vanuit het OS mijn UEFI aan te passen waarvoor je nog altijd het UEFI wachtwoord nodig hebt.

Want dat vergeet men ook wel eens, ja een UEFI is benaderbaar vanuit het OS, maar als er een wachtwoord op het UEFI staat moet je dat wachtwoord ook kennen en meegeven voor elke schrijfactie die je naar het UEFI wenst te maken.

Daarom ook dat het niet onbelangrijk is om die dingen gewoon correct te beveiligen. Maakt het een aanvaller veel moeilijker.

Maar als ik morgen mijn laptop verlies acht ik de kans dat ik Euromillions win nog altijd groter dan de kans dat ik die terugzie met enige vorm van malware op specifiek bedoeld om informatie van mij te stelen. Als ie al gestolen wordt zal het zijn om de onderdelen door te verkopen op tweedehandssites.

[HollowGamer]

Leuk, en even voor de zekerheid, je weet dat ieder bedrijf precies dezelfde manier heeft en zijn apparaten op die manier beveiligd?

[Lrrr]

Hoe zou je een machine die op deze manier is gecompromitteerd kunnen detecteren? Of stel je koopt een tweedehands machine?

[MneoreJ]

Als de aanvaller het goed gedaan heeft, feitelijk niet, want de kwetsbaarheid kan zich verbergen voor een OS. Als de UEFI firmware niet te vertrouwen is kun je heel weinig. Harddisk volledig wipen (vanaf een andere machine of een dock) zodat de EFI partitie weg is, CMOS batterij verwijderen, UEFI in, en dan proberen te flashen met een schone versie van de fabrikant (maar dat kan falen als het versienummer al "goed" is). Anders kun je per fabrikant kijken of er een optie is om de UEFI onconditioneel te vervangen.

[Blokker_1999]

De eerste keer dat je de machine opstart, direct naar UEFI gaan en de TPM wissen, daarna de UEFI resetten naar fabrieksinstellingen.

Maar als je je daar echt zorgen om maakt, nooit tweedehands kopen.

[Nibble]

Dat klopt wel, maar als iemand een levering laptops aan een concurrerend bedrijf kan onderscheppen of later en op system level een implant kan zetten en vervolgens door kan laten leveren dan kan die laptop later best als administrator geinstalleerd en beheerd worden, maar wel een hoop informatie doorsluizen zonder dat dat in de gaten loopt.

[Videopac]

Is UEFI wel echt veiliger dan klassiek BIOS?

[Visgek82]

Ja, absoluut.

[HollowGamer]

UEFI is eigenlijk een evolutie van BIOS. Je kunt beide wel met elkaar vergelijken, maar er zijn ook wat dingen anders.

@Visgek82 is er van overtuigd dat UEFI echt veiliger is, terwijl ik daar sterk over twijfel. Vergeleken met de traditionele BIOS wellicht wel, maar de BIOS was ook stukken eenvoudiger. Of Secure Boot een echte goede toevoeging is bijvoorbeeld, kan je ook betwijfelen. Die is namelijk zo lek als een mandje.

Zoek ook maar eens op LogoFail, want dat is nog wel een stuk erger. Als de rest van UEFI ook zo uitziet, dan weet je wel genoeg.

[imqqmi]

De ironie dat dit lek in een trusted platform module zit is me niet ontgaan Wat een beginnersfout om input data niet te valideren, of een buffer overflow.

[Noxious]

Daar zit het juist niet, en je bent ook kwetsbaar als je geen TPM hebt of deze niet hebt ingeschakeld.

Het zit in de UEFI firmware kant voor de connectiviteit met te TPM module, maar niet in de TPM-module zelf.

[DenHippie]

Lenovo heeft al een nieuwe bios klaar staan, iig voor mijn X1, die dit probleem verhelpt.

[Zer0]

Ben benieuwd hoeveel performance dit nu weer gaat kosten bij intel CPU's.

Het was wachten op de eerste die gaat "schoppen" tegen Intel....
Dit is geen bug in Intel CPU's, maar een bug in een firmwareversie geproduceerd door Phoenix. Feitelijk heeft het niets met de CPU te maken.

[latka]

UEFI firmware is, dacht ik, gebaseerd op de Intel reference code (maar wellicht geldt dat niet voor de Phoenix bios). Dus misschien toch wel

[Visgek82]

Heeft niets met schoppen te maken , maar met feiten. Bij heel veel cpu bugs in de afgelopen jaren heb je met een Intel cpu gewoon performance ingeleverd, knip en klaar.

Prima dat het dus geen bug in de cpu betreft dit keer.

[Jack Flushell]

Het feit is dat jij onterecht tegen Intel aanschopt in dit geval. Dat er eerder bugs waren staat er helemaal los van. Dat is ook precies wat @Zer0 zegt.

[Blokker_1999]

Ja, er zijn hardwarebugs geweest in Intel CPUs die niet met software opgelost kunnen worden zonder die functies volledig uit te schakelen wat performantie kost.

Dit is geen bug in de Intel CPU, dit is een bug in een implementatie van de UEFI voor Intel CPUs geschreven door een externe partij. Het is niet eens de reference implementatie van Intel die vatbaar is voor deze bug, enkel de specifieke implementatie van Phoenix.

En ja, dit is schoppen tegen Intel omdat je er iets bijhaalt om Intel aan te vallen terwijl Intel met deze fout niets te maken heeft.

[laptopleon]

Als ik het goed begrijp hoeft er alleen een controle te worden toegevoegd bij het instellen van een bepaalde UEFI-variabele, zodat die niet te lang kan worden. Lijkt me dat dat nihil rekentijd kost op het moment zelf en verder niet van invloed is op het reilen en zeilen op alle andere momenten.

[HollowGamer]

Niets, want dit is een security hole, en geen lek in de architectuur van de CPU-zelf.

[JeroenED]

De kwetsbaarheid , ook bekend als UEFIcanhazbufferoverflow

Is dit nu bedoeld om tegelijk het probleem met named vulnerabilities aan te kaarten? Of is een naam verzinnen gewoon verplicht geworden? Dit soort namen nemen toch de gehele serieux weg?

[Morress]

Niemand weet toch wel 'lake' processor die heeft. Ik kan dat al jaaaren niet bijhouden.