Onderzoekers vinden ernstige kwetsbaarheden in uefi

Onderzoekers van Mitre hebben twee kwetsbaarheden gevonden in uefi, het platform dat de bios voor een groot deel heeft vervangen. Een aanvaller met beheerdersrechten kan daardoor op Windows 8 bijvoorbeeld zijn eigen firmware naar de uefi-chip flashen.

De twee kwetsbaarheden stellen aanvallers in staat om werkelijk alles te doen wat ze willen, stellen de onderzoekers van Mitre, een non-profit-onderzoeksinstelling. Zo kan een computer geïnfecteerd worden met een rootkit die zelfs na het herinstalleren van een besturingsysteem aanwezig blijft. De onderzoekers bouwden bijvoorbeeld malware die permanent aanwezig is in de system management mode van x86-processors en die niet door de gebruiker kan worden opgemerkt. Daarbij kan Secure Boot worden uitgeschakeld. Ook zou een computer permanent kunnen worden gebrickt.

De kwetsbaarheden bevinden zich in de reference implementation van Intel voor uefi-chips, die door veel andere bedrijven is overgenomen. Uefi-chips van Intel zelf, evenals Phoenix, AMI en HP zijn in ieder geval getroffen. 1500 systemen van HP zouden zijn getroffen; voor die systemen zullen nu updates worden uitgevaardigd. Uefi-chips van Dell hebben wel kwetsbare code, maar een aanval blijkt niet effectief; de kwetsbare code zal voor de zekerheid toch volledig worden verwijderd. Het is onduidelijk hoe het zit met fabrikanten als Acer, Asus, Gigabyte en MSI.

De integer overflow-kwetsbaarheden zorgen ervoor dat een aanvaller zijn eigen code kan injecteren. De kwetsbaarheden zijn in ieder geval te misbruiken onder Windows 8, dat een speciale api biedt voor het bijwerken van de uefi-firmware. Het is nog niet duidelijk of ook andere besturingssystemen kunnen worden gebruikt voor een aanval op de uefi-firmware.

Onder Windows 8 moet een aanvaller wel administrator-rechten hebben om de kwetsbaarheden te kunnen misbruiken, maar daarvoor zou een andere kwetsbaarheid kunnen worden misbruikt. Zo dook onlangs nog een Windows-kwetsbaarheid op die aanvallers via Office-objecten eigen code laat injecteren; als een gebruiker als administrator is ingelogd, wordt die code als beheerder uitgevoerd.

Het is nog niet duidelijk of de kwetsbaarheid is misbruikt. De onderzoekers raden gebruikers aan om hun bios zo snel mogelijk te updaten. Ook vinden de onderzoekers dat de broncode van uefi-firmware geïnspecteerd zou moeten kunnen worden.

Reacties (69)

[begintmeta]

UEFI is eigenlijk ook onnodig complex. Dat het oude BIOS aan vervanging toe was staat buiten kijf, maar IMHO was een flexibeler/kleinschaliger systeem een betere optie geweest, ik meen dat de code van TianoCore/UEFI >250MB is...

Wat mij betreft zou de firmwre in hardware standaard beperkt zijn tot wat initialisatiecode (zoals coreboot), waarna de rest door de OS-makers kan worden afgehandeld (bijvoorbeeld eventueel door kernel/tianocore/seabios/whatever)

[Reactie gewijzigd door begintmeta op 22 juli 2024 19:36]

[halofreak1990]

Ja, maar als je ziet wat voor puinzooi UEFI eigenlijk is... Het lezen van de specificatie wordt je als OS developer niet vrolijk van, en de implementaties zijn, zo blijkt, nóg slechter.

[scsirob]

Je spreekt jezelf een beetje tegen. Flexibeler en kleinschaliger gaan niet echt samen. Ook ben ik niet met je eens dat de old-school BIOS het probleem is/was. Het probleem zit 'em in het feit dat de oude BIOS daadwerkelijk volledig controle over de hardware gaf. UEFI probeert krampachtig spelregels op te leggen die niet persé in het voordeel van de gebruiker (eigenaar...) van het systeem zijn.

Mijns inziens zou een BIOS echt het bare minimum moeten doen. De chips op het moederbord initialiseren, geheugen en PCI tabelletjes bouwen en dan heel snel een O/S booten. Geen muisgedreven bla-bla graphics setup. Gewoon het KISS principe aanhouden.

[VincentvdBergh]

Coreboot for the win.

[cilfour]

Zijn Apple systemen hier ook vatbaar voor?

[nanoChip]

Windows 8 has introduced an API that allows a privileged userland process to interface with a subset of the UEFI interface

Deze sheet pagina 13. Een Windows 8 API voor UEFI wordt 'misbruikt' voor de kwetsbaarheid in UEFI. Zover ik weet maakt Mac OSX geen gebruik van deze API of soortgelijk.

[Reactie gewijzigd door nanoChip op 22 juli 2024 19:36]

[inorde]

De kwetsbaarheid zit in Uefi, Windows biedt Api's aan die hier naartoe kunnen schrijven. Windows biedt dus een handig middel om te kwetsbaarheid te misbruiken, het is nu de vraag of andere OS-en dit ook doen.

Maar het is geen kwetsbaarheid in Windows als je het mij vraagt. De Windows Api geeft fabrikanten enkel de optie om gebruikers makkelijk hun Firmware te laten updaten, of in beperkte mate aanpassingen te doen zonder te booten naar de bios.

[Alfa1970]

Goede vraag of andere OS'en ook een API hebben waarmee dit kan.

Maar, feitelijk erg onbelangrijk, het probleem zit niet in het OS.
In theorie is dit te misbruiken zonder een OS, net zoals al bij vele eerdere problemen in UEFI het geval was.

Maar goed. Tijd om bij de hardware fabrikanten te eisen dat ze de jumper beveiliging weer terugbrengen. Gewoon een fysiek "slot op de deur".

[Kontsnorretje]

Het is nog niet duidelijk of ook andere besturingssystemen kunnen worden gebruikt voor een aanval op de uefi-firmware.

Volgens het artikel moet dat nog onderzocht worden. Ik weet wel dat ik toch gelijk even ga kijken voor een update (al dan wel voor Windows).

Edit: Als je bedoeld of hun UEFI vatbaar is, dan is dat mogelijk. Als ze ook de code sample van Intel hebben gebruikt, is er een kans dat deze bug aanwezig is.

Edit2: Als de UEFI bug aanwezig is, denk ik dat deze wel eens misbruikt kan worden als je fysieke toegang hebt. Dan kun je namelijk in single user mode in loggen (als root), en zo wellicht een aanval uitvoeren.

[Reactie gewijzigd door Kontsnorretje op 22 juli 2024 19:36]

[MrMonkE]

Iedereen gebruikt gewoon de intel meuk.
Met bugs.
Hier en daar wat aanpassingen maar de core is allemaal Intel.

[johnkeates]

Apple gebruikt een non-standaard EFI. Dat levert soms wat beperkingen op voor tweakers, maar betekent ook dat het niet erg makkelijk te wijzigen is. Standaard geeft Mac OS X je geen toegang tot EFI. Als je Windows op je Mac draait doen de Windows 8 API's dat echter wel. Maar Apple's EFI code is dan misschien wel zo anders dat deze specifieke overflow niet te gebruiken is.

Uiteindelijk weten we dat natuurlijk pas als iemand het even probeert ;-)

[Beetlejuise]

Zijn Apple systemen hier ook vatbaar voor?

en uit het artikel....

Het is nog niet duidelijk of ook andere besturingssystemen kunnen worden gebruikt voor een aanval op de uefi-firmware.

[Reactie gewijzigd door Beetlejuise op 22 juli 2024 19:36]

[halofreak1990]

Ik denk dat het @cilfour er meer om ging of de EFI firmware van Apple apparaten dezelfde kwetsbaarheid heeft. Niet per se het OS.

[Reactie gewijzigd door halofreak1990 op 22 juli 2024 19:36]

[TheReenseM]

Hier,

Punt 3: http://www.techrepublic.c...u-should-know-about-uefi/

Niet zo'n betrouwbare bron, ik zoek er momenteel meer.

[Verwijderd]

Ik denk het niet, volgens mij gebruikt een Mac een totaal ander iets om te booten dan een PC.

[arbraxas]

Dat was zo, omdat een mac uefi gebruikte ipv bios. Maar dat is tegenwoordig dus niet meer zo. En omdat Uefi dus nu op veel grotere aantallen apparaten draait is het interressant om te hacken.

[jozuf]

Macs gebruiken ook gewoon (u) efi, zie bv
http://www.cnet.com/news/...on-locks-down-newer-macs/

[Petervanakelyen]

Ja, een eigen implementatie van EFI

[Elmo_nl]

De onderzoekers bouwden bijvoorbeeld malware die permanent aanwezig is in de system management mode van x86-processors en die niet door de gebruiker kan worden opgemerkt. Daarbij kan Secure Boot worden uitgeschakeld. Ook zou een computer permanent kunnen worden gebrickt.

Dan zou je er dus goed aan doen om eerst de uefi en dan de system management mode van x86-processors te flashen met schone code voor je het OS opnieuw installeert? Kan dat nog als je al geïnfecteerd bent?

Daarbij kan Secure Boot worden uitgeschakeld.

Geeft dit ons juist niet een kans om er dan weer iets aan te doen?

[matroosoft]

Dan zou je er dus goed aan doen om eerst de uefi en dan de system management mode van x86-processors te flashen met schone code voor je het OS opnieuw installeert? Kan dat nog als je al geïnfecteerd bent?

Ik mag hopen van wel! Ander moet je gewoon even je moederbord vervangen..

[Alfa1970]

Ja, eentje die made in China is zekers ...

[Neko Koneko]

Je bedoelt zoals alle moederborden? (Behalve die in Taiwan gemaakt worden dan)

[Markcortbass]

Hierbij dus een bewezen proef dat 'secure boot' niets anders is dan een hardwarecontrole om het installeren van andere besturingssystemen moeilijker te maken.
Ik ben benieuwd of Linux distro's de UEFI firmware behandelen zonder kwetsbaar te zijn, t.o.v. windows.

[_JGC_]

Linux kan prima met secure boot overweg, daarvoor zijn signed kernels of signed bootloaders bedacht.
Verder kan je juist vanuit linux veel aan de hardware klooien. Grote kans dat de benodigde EFI vars gewoon in sysfs staan.

[SunnieNL]

Secure boot zit NA de UEFI en checked de bootloader van het os op manipulatie, niet het ueFI gedeelte

[0vestel0]

".....aanvaller met beheerdersrechten.....".
Toen ben ik gestopt met lezen. Dit is toch geen kwetsbaarheid?

[proatjeboksem]

".....aanvaller met beheerdersrechten.....".
Toen ben ik gestopt met lezen. Dit is toch geen kwetsbaarheid?

Dat was ook mijn eerste gedachte. Ik kan ook een pc of laptop bricken als ik er fysiek toegang tot heb.

Maarja, ome Jan, tante Pien en de gemeente den Haag werken op hun machientje natuurlijk als admin en als ze dan op een track & trace mailtje klikken....

[itlee]

Het was een keer te verwachten, de oude old scool bios kon niet veel maar was ook niet enorm kwetsbaar. Nu ga je voor t os kan laden een berg mogelijkheden bieden met als gevolg dat je t os laad je al in de ellende kan zitten.

De gemiddelde consument update zijn Windows al niet dus laat staan dat ze de bios updates doen....+ dat een consument altijd local Admin is.....

Ik voel voorzichtig een old scool RPC virus aankomen die de nodige netwerken zal platleggen.

Edit; typo verwijderd

[Reactie gewijzigd door itlee op 22 juli 2024 19:36]

[Fatchicken]

Dit soort dingen zie je steeds vaker in het nieuws wanneer er naar een nieuwe techniek wordt overgestapt, gevalletje kinderziekte als je het mij vraagt, niets wat niet met een update opgelost kan worden.
Het zou ook wat zijn als we tot 2050 op oude software blijven hangen puur omdat dat op het moment maar het veiligst is .

[Reactie gewijzigd door Fatchicken op 22 juli 2024 19:36]

[teacup]

Een logische reactie is om in de richting van een BIOS update te denken. Ook kan het vanuit het OS not done zijn om het BIOS te kunnen benaderen. Een update doen is toch het meest stabiel met een update tool, die voor zichzelf natuurlijk ook weer een beperkte omgeving creëert.. Maar eigenlijk heeft het OS niets in het BIOS te zoeken. Scheiding van machten, wat mij betreft.

Het is nog niet duidelijk of Windows 8 het enige OS met een dergelijke api. Ook is het nog niet duidelijk of de weg vanuit het OS de enige route is om op afstand kwetsbare BIOS code te misbruiken. Dit kan wat dat betreft nog een sneeuwbal worden. En dan moeten we toch terecht bij de fabrikanten langs voor BIOS updates. Gatverdamme, weer een klusje erbij.

[Reactie gewijzigd door teacup op 22 juli 2024 19:36]

[winos]

Een positieve uiting van dit "lek" zou de volgende gebeurtenis met zich mee kunnen brengen.
In theorie zouden de dames en heren programmeurs van een groot forum software kunnen schrijven die de "signage en signature check van apps van het Windows RT platform omzeild. Hiermee doel ik op X86 programmatuur. (Gewoon voor testdoeleinden...)

(Slechts een gedachtekronkel die bij mij opkwam. Of dit correct is kan ik niet bevestigen en hier zullen anderen weer meer van weten dan ik.)

Persoonlijk denk ik, dat als deze theorie daadwerkelijk functioneel blijkt te zijn niet dat Microsoft dit op prijs gaat stellen. Het is dan op dat moment ook wachten totdat Microsoft een update uitrolt.

[z1rconium]

De onderzoekers hebben dit bij de betreffende partijen hebben gemeld en datum voor bekendmaking hebben neergelegd (op blackhat).

Intel Vulnerable, fixed in January & released in UDK2014
Phoenix Vulnerable, fixed (see next slide)
Insyde Not vulnerable (see next slide)
AMI Vulnerable, fixed (see next slide)
HP Vulnerable, fixed (see 4 slides from now)
Dell Suspect code found with binary analysis, but is dormant and will
be quarantined or removed in upcoming releases.
Lenovo Incorporating Phoenix updated source code

Ik kan me niet voorstellen dat dit is misbruikt, het is een bijzonder complex verhaal en er is een behoorlijke paper voor nodig om uit te leggen hoe het werkt en als je dan eerst de fabrikanten op de hoogte brengt voordat je het openbaar maakt, lijkt het me zeer sterk dat er andere slimme jongens zijn die op hetzelfde spoor zitten.

[TheHummer]

http://webwereld.nl/bevei...it-slaat-gat-in-windows-8

2 Jaar geleden kwamen beveiligingsonderzoekers hier ook al mee op de proppen.
Je zou toch wel verwachten dat hier wat zorgvuldiger mee omgesprongen zou worden.