Beveiligingslek in x86-chips gedemonstreerd

Tijdens de CanSecWest/core06-conferentie, zeg maar: een Canadese variant van WhatTheHack, is bekendgemaakt dat de TOP-functionaliteit van x86-processors door hackers misbruikt kan worden. Volgens Loïc Duflot, een computerbeveiligingsexpert van de Franse overheid, is het mogelijk om de routines die normaal gesproken bijvoorbeeld worden uitgevoerd als de cpu te warm wordt, aan te wenden om toegang te krijgen tot de System Management Mode. Daar zou een hacker vervolgens eigen code kunnen achterlaten, die hem volledige toegang tot het systeem biedt. SMM biedt namelijk een van de rest van de cpu afgezonderd stukje geheugen, maar de code die daarin draait heeft wel toegang tot de rest van het computergeheugen.

De hack zou met uitsluitend officiële en gedocumenteerde functionaliteit uitgevoerd kunnen worden, en dus niet berusten op misbruik van bugs. Als kwetsbare cpu's worden onder andere de Pentium 4 en de Xeon genoemd, maar SMM wordt al sinds de 80386 in de x86-architectuur toegepast, zodat zonder meer mag worden aangenomen dat ook alle courante AMD's met het beveiligingslek te stellen hebben. Een proof-of-concept-exploit zou onder FreeBSD werkend gedemonstreerd zijn, maar de getoonde werkwijze zou onder andere besturingssystemen ook werken. De kwetsbaarheid is wel in te dammen, maar diverse maatregelen gaan ten koste van de functionaliteit van een machine. Zo moet bijvoorbeeld het gebruik van de grafische X-server, vanwege de hardwaretoegang die deze nodig heeft, als inherent onveilig worden gezien. De opvallendste uitzondering in de lijst kwetsbare besturingssystemen is Windows XP: de 'privilege escalation'-techniek die Duflot beschrijft, is bij het OS van Microsoft niet uit te voeren. Hoewel Duflot als onafhankelijk mag worden aangemerkt, moet daarbij wel vermeld worden dat Microsoft het CanSecWest-evenement sponsort.

Reacties (61)

[The - DDD]

Attackers then enter the System Management RAM and replace the default emergency-response software with custom software that, when run, will give them full administrative privileges.

Ik lees bovenstaande in de bron van dit nieuws item.

Wat hier precies geimpliceerd wordt weet ik niet. Maar hoe kan je in vredesnaam remote de RAM accessen als het systeem aan het interrupten is. Mijn onderbuik gevoel zegt dat voor deze exploit wel eens fysieke toegang noodzakelijk is. Als dat zo is, dan wordt de ernst van deze bug ineens een heel stuk minder. Iemand enig idee? Ik kan namelijk niet meer info vinden hierover via "de bron".


edit:
Holly koei!! Heb het linkje naar de ppt file in het nieuws item gevonden en bekeken. Dit is echt serieus. Enige wat je nodig hebt is superuser/root toegang. Als je dat hebt is het allemaal remote uit te voeren als ik de stukjes assembler code zo zie.

[Aaargh!]

Enige wat je nodig hebt is superuser/root toegang.

Maar als je superuser/root bent, dan heb je toch al volledige controle over de machine

[The - DDD]

Niet helemaal. Want een root zit nog steeds binnen de grenzen van protected mode als ik het goed heb. Kan iemand met meer kennis dit bevestigen?

[Aaargh!]

Ik heb de presentatie ook even bekeken, wat ik er uit opmaak is het volgende:

Hij heeft het over OpenBSD, waar er een extra beveiligingsmode is die het zelfs voor root niet mogelijk maakt direct het geheugen aan te spreken. Met deze exploit kan je als je al root bent je rechten escaleren zodat je dit wel kan, dit maakt deze extra security laag nutteloos. Linux kent v.z.i.w. niet zo'n security mode (root heeft al volledige toegang) dus daar kan dit wel maar je hebt er niks aan.

Ook de oplossing lijkt erg eenvoudig, met een paar instructies tijdens het booten kan dit stuk geheugen 'op slot' gezet worden (volgens die presentatie) waardoor deze exploit niet meer werkt, dit kan je dus in je kernel zetten of e.v.t. in een BIOS update. (eerste lijkt me praktischer)

[needless to say]

Ik ben ook even aan het speculeren, maar wat als je een microcode-update zou kunnen doorvoeren vanuit een virus/worm uit die vervolgens die code uitvoert bij de volgende microcode-update? BIOS-flashen kan nu toch zo makkelijk vanuit windows bij de meeste pc's.

Uiteraard zit je met het probleem dat er zoveel verschillende pc's zijn. Maar aangezien de meeste grote bedrijven met grote contracten zitten voor de aankoop van hun pc's, is het wel vaak het geval dat de meeste pc's van 1 bedrijf practisch identiek zijn. Even een custon BIOSje aanmaken voor dat type pc en je hebt heel het bedrijf geïnfecteerd.

Trouwens, kun je deze functies die uitgevoerd worden bij het te warm worden van je CPU niet gewoon uitschakelen?

[The - DDD]

Hmm ja, maar het heeft dus niks met je systeem BIOS te maken volgens mij.

Deze functionaliteit is er als bescherming van oververhitting van je systeem. Dit gaat via een hardware interrupt, daardoor gaat de CPU gewoon een tijd lang helemaal niks doen, zelfs geen idle cycles draaien en dus minder warmte produceren. De system management code zorgt hiervoor.

[needless to say]

Maar wordt die code enkel uitgevoerd bij oververhitting? Of constant voor het checken op oververhitting (en later het counteren van de oververhitting)?

Anders zorg je gewoon voor een goede koeling

[The - DDD]

Je kan interrupts ook afknallen via assembler zie ik in de presentatie. Dus misschien kan een bios update dit toch voorkomen?

Geeeeen idee eigenlijk. Zo goed zit ik niet in de materie.

[MrMr]

Nog leuker, je moet zo te zien als root de exploit installeren en dan het systeem rebooten om hem te gebruiken (lees de presentatie er maar op na).

Niet echt indrukwekkend. moet je eens "cd /;rm -rf *" doen onder die condities (dat is ook een cross-platform attack; en voor meer architecturen dan alleen x-86).

[FlorisB]

rm -rf /* ? Waarom cd?

Echt cross-platform is t niet.. windows werkt t niet.. Alleen *NIX kernels..

[Verwijderd]

De "Windows"-vorm van dat regeltje is lichtjes anders, nl. "cd \; del *.*", het wist gewoon elk bestand van je schijf

[Verwijderd]

Reactie op Lake:

Niet hoor, dat regeltje verwijderd elk bestand dat recht op de schijf staat. Mappen en de bestanden daarin blijven staan.

[MrSpacely]

Tuurlijk doet windows niet aan filelocking(dus wel), zo'n commando doet dus echt bar weinig. paar bestandjes weg

[Verwijderd]

cd\
del /FSQ *.*

[Strike_2]

hall jij maareens boot.ini, ntldr of ntdetect.com weg...

Het zou je verbazen ale je eens wist wat er in io.sys en msdos.sys stond...

Ja, _zelfs_ in XP bestaat die reut nog.
Of het nut heeft is een ander verhaal...

[Parasietje]

Tja, dit kan je natuurlijk niet zomaar even onzeilen. Kwetsbaarheden die inherent in chips zitten, zijn HEEL gevaarlijk. Weet iemand of dit met een microcode-update op te lossen zou zijn?

[Damsplaat]

zou dit dan de eerste multi-OS exploit zijn die niet onder windows werkt?

[SED]

Sterker nog, juist de ruime mogelijkheden van unix varianten maken die extra kwetsbaar.
Zo mag je dus verwachten dat OSX na hun overstap naar Intel ineens een fikse kater dreigt op te lopen.


De suggestie onderaan dat MS het event als sponsor steunt is nogal tendentieus! dat hoort niet op tweakers. Is dit het werk van een anti-MS figuur of gewoon foute journalistiek?

Dat Windows voor deze techniek niet kwetsbaar is zegt niets over de onveiligheid van de andere systemen waar dit artikel over gaat.

[Verwijderd]

Dat heet [full] disclosure, mogelijke links aangeven en aan de lezer overlaten wat hij er van denkt; dat is correcte journalistiek en wettelijk verplicht in de VS.

De formulering in het nederlands [moet je effe checken met origineel --- (disclosure ) heb ik niet gedaan] is wel degelijk tendentieus, maar beschuldigt niet.

[Verwijderd]

Wat een onzin. Moet er bij iedere constatering van een lek/bug/exploit in Windows gemeld worden of de ontdekker Linux draait of wel eens betrokken is geweest bij een Open Source project? Dat Microsoft het event sponsort zegt helemaal niets. Als de man nou in dienst was van Microsoft, of werkte voor een bedrijf met "verdachte" relaties met Microsoft... De link naar de site van het event is gegeven en het eerste dat daar staat bij sponsors is Microsoft. Er is niets achtergelaten. Het expliciet melden van Microsoft als sponsor plaatst dit bericht júist in kwaad daglicht.

[dasiro]

inderdaad, alsof MS hem heeft opgedragen naar een exploit te zoeken die op alle OS'en werkt, behalve hun laatste nieuwe.

wel enorm vergezocht imho

[Verwijderd]

De opvallendste uitzondering in de lijst kwetsbare besturingssystemen is Windows XP

Alleen XP is niet kwetsbaar volgens het artikel, de andere Windows varianten wel. Aangezien het grootste deel inmiddels XP draait is het niet zo interessant voor kwaadwillenden om misbruik van het lek te maken. Ik hoop dat Vista ook imuun is.

[Cookie]

Aangezien wellicht veel (semi)overheidsystemen wat ouder kunnen zijn, zou het dan niet juist wel riskant zijn m.b.t. 'kwaadwillenden'?

[atlaste]

Dat zie je denk ik verkeerd. Een shell op een linux box is een stuk interessanter voor een hacker dan een virus of een dos prompt op een windows box.

[Verwijderd]

Dat denk ik niet hoor... Denk je het volgende scenario eens uit:

je maakt hier een virus voor, die gebruik maakt van deze exploit. Zodra het virus op het systeem staat haalt hij een "normaal" virus binnen wat WEL werkt op XP en gaat dat verspreiden.

Als je het op die manier doet kan je binnen het bedrijf waar ik werk een 30.000 pc's wereldweid op enkele MINUTEN infecteren, en das niet omdat we slechte beveiliging hebben... Als je de WSUS server op dit datacenter infecteerd word het automatisch verspreid over alle WSUS servers van ons wereldweid en halen de clients het virus ook af.

Kortom: ook al gebruiken de meeste mensen XP wat hier blijkbaar imuun voor is, het is nog altijd een zeer gevaarlijke exploit.

[reddog33hummer]

Als je de exploit bekijkt gebruiken ze hem om in het geheugen aan te passen als root. Voor windows zou dit betekenen dat je als administrator als system geheugen kan veranderen. Dit is een securityoptie die aan en uit gezet kan worden (user can imitate system).

Het grote probleem is alleen dat windows in de kernel met signatures van het geheugen heeft. Dus de exploit zal dan wel werken, maar dan moet je die signaturen updaten anders is de page fault, en wordt hij uit gewisseld. Daarom werkt hij nu niet, maar zou het wel kunnen.

[ShellGhost]

Niet onder XP, blijkbaar wel bij alles ouder dan XP of gelijke kernel.
Dus 2003 server en consorten zal ook "veilig" zijn.

/Edit
Vista zal vermoedt ik wel "imuun" zijn aangezien die voortborduurd op de xp/2003 kernel als ik het goed heb.
Die funcionaliteit zal wel meegenomen worden naar nieuwe versies.

Ik vraag me af of de nieuwe 64bitters daar ook last van kunnen hebben.
Aangezien ze ook nog steeds een stuk(je) 32bit code hebben.

[Chatslet]

@Son-Gohan:
Best interessant wat je daar op noemt. 64 bitters hebben namelijk de zogenaamde NX-Bit die er voor zorgt dat ieder progsel in ze eigen stukje geheugen blijft en er geen buffer overflows plaats kunnen vinden. Vraag me dus af of dat hier zal helpen.

[SPee]

Zou hier dan niet een virus voor geschreven kunnen worden die een VM aanmaakt voor je systeem.
Dan is je systeem echt volledig geinfecteerd, zonder dat jij het ooit zult weten. hopen dat ik niemand op gedachten breng

[Zarc.oh]

Rootkits met dit idee zijn al ontwikkeld, zie nieuws: Onderzoekers ontwikkelen virtual-machine rootkit
Dus het is net zo makkelijk om op basis van hetzelfde een virus te maken.

[Wouter Tinus]

Ik zou dit geen "lek in x86" willen noemen. De chips doen namelijk precies wat ze volgens de documentatie moeten doen: het is gewoon een feature die kennelijk al twintig jaar aanwezig is. Dat de ontwerpers van bepaalde operating systemen geen rekening met deze functie hebben gehouden bij het bouwen van hun hoger-dan-root beveiligingsniveau is natuurlijk wel opzienbarend, maar het lijkt me overtrokken om de hardware daar de schuld van te geven.

[Rataplan]

Dit is geen bug, zoals het artikel ook stelt, maar wel een lek, en dat de hardware-bouwers niet voor het misbruik verantwoordelijk zijn, maakt het misbruik nog niet minder mogelijk. PPC niet kwetsbaar, x86 wel, dan kan ik wel roepen dat *BSD onveilig is maar daar zit het eigenlijke probleem natuurlijk niet in.

En het is echt een tamelijk fors lek, want het SMM-geheugen wordt afaik door geen enkel (virusscan-, chkrootkit-)programma gecontroleerd. Daarmee kan een hacker niet alleen een x86-systeem onder controle krijgen, maar het in theorie ook ondetecteerbaar (!) onder controle *houden*. En dat alles dankzij een onderdeeltje van de x86-architectuur dat zich twintig jaar braaf heeft gedragen...

[Wouter Tinus]

Het enige lek is dat het OS niet controleert wie of wat er naar dat SMM-geheugen schrijft. Zoals ik het begrijp heeft geen enkele gebruiker (ook niet root) daar iets in te zoeken, dus ja, BSD en Linux laten hier een steek vallen. Microsoft heeft het kennelijk wel goed voor elkaar.

Laat ik het anders stellen: hoe zou dit volgens jou aan de hardwarekant opgelost moeten worden?

[Olaf van der Spek]

Zoals ik het begrijp heeft geen enkele gebruiker (ook niet root) daar iets in te zoeken, dus ja, BSD en Linux laten hier een steek vallen.

Moet ik me als Windows beheerder veilig voelen als iemand administrator access tot mijn server heeft?

Het is leuk dat het onder Windows niet direct kan, maar volgens mij maakt het effectief niks uit.

[Rataplan]

Wie heeft het over oplossen?

Ik constateer alleen dat er een gat in de architectuur zit waar water door naar binnenkomt. Dat dat gat verder heel nuttig is, wil niet zeggen dat er niet een luikje bij gezocht moet worden.

Bij springtij is iedereen achter de zeedijken niet veilig, tenzij er ook rivierdijken liggen. Het enige wat ik vaststel is dat de zeedijken een gat vertonen, en wel omdat er een rivier (nou ja, een slootje) in zee uitmondt. Hoe en door wie er nu rivierdijkjes opgetrokken gaan worden is mijn zorg niet Dat jij het nodig vindt om de processorfabrikanten te verdedigen tegen niet-geuite beschuldigingen, tja, daar kan ik ook niks aan doen

[Wouter Tinus]

"Ik constateer alleen dat er een gat in de architectuur zit" en "Beveiligingslek in x86-chips" (titel)

vs. "niet-geuite beschuldigingen" .

Een processor(architectuur) is maar tot op zeer beperkte hoogte verantwoordelijk voor de beveiliging van een systeem: het gescheiden houden van verschillende threads en virtuele geheugenruimtes (plus sinds kort volledige virtualisatie), het bewaken van priviledged instructies in verschillende ringen en eventueel nog voorkomen dat data als code uitgevoerd wordt. Geen van deze punten wordt overtreden, ook niet bij "springvloed". Voor de rest is een processor gewoon een stom ding wat precies doet wat hem wordt opgedragen. Als BSD en Linux daar geen rekening mee houden door root gewoon té veel rechten te geven om de processor opdrachten te geven, dan is dat hun probleem, niet dat van die processor.

Een lek/gat is iets wat ergens onbedoeld insluipt. Dit werkt gewoon precies zoals het ontworpen is aan de kant van x86. Onder BSD/Linux kan een slimmerik er echter meer mee doen dan de ontwikkelaars hebben beseft. Dát noem ik pas een gat, in die OSsen dus. Zoals jij denkt over "gaten" kun je iedere exploit wel terugvoeren tot een "lek in x86", tot een domme bufferoverflow aan toe. Uiteindelijk is het namelijk altijd de processor die de malafide code uitvoert, simpelweg omdat ie niet beter weet.

[Verwijderd]

Zover ik het begrijp: als je eigen code wil achterlaten die de SMM dan zal uitvoeren, dan moet je wel in het geheugen kunnen schrijven. Ofwel: je hebt hoe dan ook al root access nodig.

Dus je hebt root access nodig.. om een exploit binnen te loodsen die.. ook root access geeft?

Wat is dan daar het nut van, afgezien van de uitdaging voor de hackers die dit hebben uitgeknobbeld?

[The - DDD]

Nee het punt is dat je willekeurig al het geheugen in het systeem kan aanpassen. Dit kan gebruikt worden om root te krijgen, maar die heb je al om dit te doen, dus wat is het nut.

Nou je kan dus willekeurig alles in het geheugen van het systeem aanpassen. Iets wat zelfs root niet zomaar kan volgens mij want je draait in protected mode wat volgens mij betekend dat je niet zomaar geheugen segmenten in het geheugen kan benaderen van een ander proces dan je eigen.

Stel je eens voor dat dit op een kritisch systeem komt en door deze exploit worden drempel waarden van een beveligings systeem in het geheugen gemodificeerd. Leuk als die drempel waarden voorkomen dat je kern reactor oververhit bijvoorbeeld. (Knappe jongen als je dat kan.)

De truuk is dat deze exploit je toegang geeft die nog veel verder gaat dan root.

[Verwijderd]

Wat ik weet van 386 memory management in protected mode is het volgende: je segment register bevat geen segmentnummer maar een speciaal indexnummer voor een descriptortabel. Er zijn er twee: globale descriptortabel, en lokale descriptortabel. Wil je dergelijke segmenten aanmaken en beheren als memory manager dan lijkt het me dan toch wel dat de kernel (en dan ook root, al dan niet met een tussenweg) zelf deze segmenten moet kunnen beheren, anders kan deze ook geen segmenten verder aanmaken. In die trend kan root toch ook al het geheugen aanspreken? Of zie ik iets over het hoofd met betrekking tot implementatie van de kernels van Linux en BSD?

Ik ga ervan uit dat beide descriptortabellen door de kernel beheerd worden: dat moet eigenlijk ook wel, omdat de BIOS die in ieder geval niet beheert.

Na het instellen van protected mode ben je zelf ook verantwoordelijk voor deze segmenteringen, en in die zin heeft de kernel ook vat over het hele geheugen.

[Arcane Apex]

SMM biedt namelijk een van de rest van de cpu afgezonderd stukje geheugen, maar de code die daarin draait heeft wel toegang tot de rest van het computergeheugen.


Dit is tevens een eigenschap van Trusted Computing of Trusted Platform Computing welke dit jaar standaard in hardware zal komen.
Er zullen dan stukken geheugen in chips op de hardware ontoegankelijk gemaakt worden, waarbinnen code draait die ge-encrypt is.
Volledige controle over je machine zal dus verleden tijd worden door de eigenschappen van deze obscure ontoegankelijke geheugensecties.

[GeeBee]

.. bijvoorbeeld als de processor te warm wordt...

Zorgen dus dat dat niet gebeurt, door installatie van een ICEwall ipv FIREwall???

[merethan]

"even updaten"

shit CPU ken je niet updaten!

[Parasietje]

Toch wel, een CPU draait een soort microcode, die hogere requests vertaalt in een aantal basalere commando's. Deze microcode kan je wel updaten.
(zie onder, dit is een dubbelpost, I know...)

[Atlas]

U gaat niet door voor de koelkast

AMD heeft een aantal CPU's waar je ook firmware in kan flashen om bugs op te lossen. Dit hebben ze in het verleden al eens gebruikt om een aantal vervelende bugs op te lossen.
Dus wie weet komen ze hiervoor ook met een firmware update

[My-life]

Dat is niet geheel waar.
Lees hieronder maar bij Parasietje.

[Verwijderd]

apt-get install newcpucore

[Verwijderd]

Leuk voor Windows ... een cpu met adware en spyware.

[Hammer-to-Fall]

Misschien een rare vraag maar hoe kom je er überhaupt op om dit te onderzoeken?

[trogdor]

Zeg, ben jij nou een tweaker of niet

[Hammer-to-Fall]

Daarom stel ik mijn vraag dus ook; Ik zou wel willen weten waarom Loïc Duflot dit onderzocht heeft. Meestal is er een reden of aanleiding om zoiets te onderzoeken.