Onderzoekers omzeilen beveiligingsmaatregel door aanval op cpu

Onderzoekers hebben een methode gepresenteerd om de beveiligingsmaatregel aslr te omzeilen. Dit doen zij door een cpu-onderdeel aan te vallen met een zogenaamde side channel-aanval. Zij voerden de aanval met succes uit op een Intel i7-cpu van de Haswell-generatie.

Door de aanval is het mogelijk om aslr te omzeilen, schrijven de onderzoekers in hun paper. Aslr is een beveiligingsmaatregel die in veel besturingssystemen aanwezig is, bijvoorbeeld Windows, OS X en Linux. De techniek moet aanvallen op het systeemgeheugen, bijvoorbeeld stack overflows, moeilijker uitvoerbaar maken. Met een dergelijke aanval is een aanvaller in staat om willekeurige code op een systeem uit te voeren. Aslr bemoeilijkt dit door willekeurige locaties in het virtuele geheugen aan te wijzen waar programma's belangrijke componenten kwijt kunnen, leggen de onderzoekers uit.

Zij schrijven dat hun aanval gericht is op de branch target buffer, die onderdeel is van de branch predictor. Deze is aanwezig in cpu's om snelheidswinst te boeken door te voorspellen welke kant een bepaalde branch opgaat. De buffer slaat daarbij de adressen van recent uitgevoerde instructies op en wordt gedeeld door verschillende processen. Door een botsing te veroorzaken tussen een kwaadaardig proces op gebruikersniveau en een ander gebruikersproces zijn de onderzoekers in staat om te voorspellen op welke plaatsen in het geheugen processen code uitvoeren. Door aslr zou dit juist niet mogelijk moeten zijn.

De onderzoekers voerden de aanval succesvol uit op een Intel Core i7-4800MQ quadcoreprocessor in combinatie met Ubuntu 14.04. Zij maken niet duidelijk of alleen Haswell-processors kwetsbaar zijn voor deze methode of dat ook andere generaties of cpu's van andere fabrikanten risico lopen. Ars Technica schrijft dat een Intel-woordvoerder het paper onderzoekt. Aanvallers kunnen de nieuwe aanval gebruiken in combinatie met andere malware om een systeem binnen te dringen, aldus de site.

Volgens de onderzoekers, verbonden aan de universiteiten van New York en Californië, zijn softwarematige oplossingen voor dit probleem beperkt. Een hardwarematige oplossing zou beter werken, bijvoorbeeld door botsingen in de buffer te voorkomen die een aanvaller kan misbruiken.

Reacties (23)

[Jurrian120]

Ben wel benieuwd of dit geld voor de gehele Haswell lineup, of dit ook geld op de Haswell refresh (Devil's Canyon) en ook voor Haswell-E.

[NL-RaVeR]

Ik vermoed dat het niet alleen voor Haswell geld, maar ook voor de generaties ervoor en mogelijk ook voor de generaties erna. Aangezien ze aangeven dat het vermoedelijk hardware matig opgelost moet worden en dit niet eerder bekend was, is dit mogelijk nog niet opgelost in nieuwere generatie processors.

Wat ik me wel afvraag is of ook cpu's van andere fabrikanten vatbaar zijn, zoals AMD en Qualcomm.

[Verwijderd]

Ik vermoed dat het niet alleen voor Haswell geld, maar ook voor de generaties ervoor en mogelijk ook voor de generaties erna. Aangezien ze aangeven dat het vermoedelijk hardware matig opgelost moet worden en dit niet eerder bekend was, is dit mogelijk nog niet opgelost in nieuwere generatie processors.

Dat moet je precies weten wanneer welke Branch predictor in een specifieke CPU gekomen is. Ik kan me voorstellen dat bij een andere minder snelle Branch predictor dat niet zo optreed.
Uit wiki: Branch predictor

Branch predictors play a critical role in achieving high effective performance in many modern pipelined microprocessor architectures such as x86.

Hoe ik het lees, hoe sneller de Branch predictor gokt hoe sneller de CPU zal zijn c.q. hoe minder deze geremd zal zijn. Lijkt me een duivels dilemma, wil ik een ultra snelle processor of ga ik voor meer veiligheid ten koste van de snelheid.
Als ik het goed begrijp zou dit probleem niet bestaan hebben als er geen Branch predictor in de CPU zou zitten.

Wat ik me wel afvraag is of ook cpu's van andere fabrikanten vatbaar zijn, zoals AMD en Qualcomm.

Gokje, zou kunnen.
Zo ja, waarschijnlijk niet op de zelfde manier, want dan zouden ze allang een rechtszaak aan de broek gehad hebben als ze Branch predictor implementatie van Intel gekopieerd zouden hebben.

[.oisyn]

(Als aanvulling op @unglaublich hierboven)

Zoals aangegeven gaat het er niet om hoe snel een branch predictor werkt, maar hoe goed hij gokt. Gokt hij goed, dan is het snel, anders is het langzaam. Het is dus vrij binair, ongeacht de implementatie van je branch predictor. En je kunt dus ook gewoon meten of de CPU juist heeft voorspeld of niet.

Waar het in dit geval mis gaat is het feit dat er voor elke uitgevoerde jump die in de code staat, metadata moet worden bijgehouden. Hiervoor gebruik je het adres van de instructie als key om de lookup te doen naar de juiste metadata. Net als met cache geheugen, is de "branch target buffer" (BTB) in de regel niet fully associative maar slechts set associative om complexiteit en geheugen uit te sparen. En integenstelling tot de cache, is het niet erg om in het geval van branch prediction verkeerde waardes uit te lezen - het leidt hooguit tot een verkeerde prediction, niet tot fout gedrag. Er wordt dus slechts een beperkt aantal bits van het virtuele adres van de jump instructie gebruikt om de lookup te doen. En integenstelling tot bij cache geugen, wordt er niet de moeite gedaan om te kijken of de rest van het adres ook klopt.

Het gebruiken van een beperkt aantal bits leidt tot collisions. Verschillende jump instructies kunnen in hun adres dezelfde bits hebben zitten die gebruikts wordt voor de lookup. Het kan dus zomaar zijn dat een branch in user code collidet met een branch in kernel code. En met dat in je achterhoofd, alsmede het feit dat je kunt meten of er juist voorspeld werd, kun je vervolgens onderzoek gaan doen naar het aantal bits dat daadwerkelijk gebruikt wordt in de BTB. Door gebruik te maken van verschillende processen met een jump instructie, waarbij het ene proces de BTB vult door heel vaak te jumpen, en het andere proces herhaaldelijk hetzelfde doet en zijn jumps timet en telkens 1 bit van het adres wijzigt waarop het alemaal gebeurt, kan uiteindelijk worden achterhaald hoeveel en welke adresbits worden opgeslagen in de BTB.

En als je dát weet, kun je op eenzelfde manier een collision proberen te vinden met een willekeurige jump in kernel space, waarbij je je jump instructie steeds opschrijft, alsmede de jump target. Met een beetje mazzel, en dat was ook hier het geval, was het aantal bits in de BTB groot genoeg om de address randomization van de kernel te achterhalen.

Andere typen processoren slaan niet per se dezelfde bits op in de BTB, maar je kunt er donder op zeggen dat ze het op een vergelijkbare manier implementeren. En je kunt dus in principe live achterhalen hoeveel bits er gebruikt worden, zoals de onderzoekers hebben gedaan. Het aantal processoren dat kwetsbaar is voor deze aanval lijkt me dan ook een stuk groter dan alleen deze specifieke Haswell i7 chip.

De OS vendors zouden hier in principe wel iets tegen kunnen doen. De address randomization bits moeten gewoon altijd buiten het bereik van de BTB blijven.

[Reactie gewijzigd door .oisyn op 23 juli 2024 15:56]

[unglaublich]

De branch-predictor is niet per definitie een veiligheidsgevaar maar is door een implementatie probleem in o.a. de genoemde i7 een kwetsbaarheid geworden.

Een branch-predictor gokt niet sneller of minder snel maar kan alleen slimmer gokken. In een moderne CPU worden instructies in een aantal stappen uitgevoerd, een pipeline. Elke stap wordt door een ander mechanisme uitgevoerd en wanneer een instructie naar de volgende stap gaat wordt er weer een nieuwe instructie in het voorgaande mechanisme geladen. Wanneer de CPU een branch instructie (een soort if) tegenkomt kan het zijn dat de CPU naar een andere regel programmacode moet. De CPU weet dit echter pas in een later stadium van de meerdere stappen waarin een instructie wordt uitgevoerd. In dit geval zijn de instructies die nog in de pipeline zitten onbruikbaar en moet de CPU de volgende instructie van voren af aan verwerken.

De branchpredictor probeert te gokken wat de CPU gaat doen en laadt het meest waarschijnlijke verloop van instructies in de pipeline waardoor er minder vaak overnieuw begonnen moet worden met het uitreken van een instructie.

[RDNZN]

De onderzoekers voerden de aanval succesvol uit op een Intel Core i7-4800MQ quadcoreprocessor in combinatie met Ubuntu 14.04.
In ieder geval wel voor de i7 4800MQ.

[mavamal]

Artikel gelezen, en nu vraag ik me af: als je er van uit zou kunnen gaan dat niemand je computer aanvalt, hoeveel sneller en efficienter zou hij dan kunnen werken?

[Verwijderd]

Artikel gelezen, en nu vraag ik me af: als je er van uit zou kunnen gaan dat niemand je computer aanvalt, hoeveel sneller en efficienter zou hij dan kunnen werken?

Je kunt er sowieso alleen van uit gaan dat niemand je Computer aanvalt als je:
1) Niet met een netwerk verbonden bent.
2) Niemand anders dan je zelf op de Computer mag.
3) Je geen media gebruikt op de computer die ook op andere computers gebruikt worden, of zelfs beter helemaal geen media. Want zelf op nieuwe media staat soms kwaadaardige software.

Hoeveel sneller een PC zou zijn zonder beveiligingsopties. geactiveerd. Dat is iets dat ieamnd zou uit moeten zoeken. Sommige veiligheidsopties kun je deactiveren zoals bijvoorbeeld het NX bit. Of dat bij aslr ook mogelijk is, weet ik niet, nooit in verdiept. Even gezocht, in 2012 kon het nog in Linux, of het nu nog kan?
Disabling ASLR and NX in Linux

Ik zou deze opties nooit uitschakelen op een PC waar belangrijke data op staat. Ik zou me van een kant voor kunnen stellen dat het leuk zou zijn voor een game PC om maximale performance te halen. Maar als deze via het internet verbonden is, weer niet omdat iemand zo je password ontfutselen kan. Ik neem dat voor een gamer zijn/haar game account belangrijk is.

[analog_]

dit soort opties zijn gratis. de nx bit was bijvoorbeeld voor hw implementatie in bsds en nixes kernels al aanwezig (32bitters) waarbij de kost verwaarloosbaar was.

[TheGhostInc]

Een groot deel van de kwetsbaarheden zijn 'keuzes' in de implementatie die prima andersom opgelost kunnen worden.

Daarnaast zijn sommige kwetsbaarheden ook gewoon fouten in de implementatie. Het is vervelend dat ze te misbruiken zijn, maar dat betekent niet dat zonder 'misbruik' het gedrag wel goed zou zijn. BSOD's of vastlopende machines zijn de 'normale' resultaten van deze problemen en niet wenselijk.

[svennd]

Sneller en efficiënter zijn twee vragen, maar sowieso is de CPU maar weinig de bottleneck in dagelijks gebruik...

[Jogai]

Maakt denk ik niet uit. Een proces die in het geheugen blok 1,2,3,4 uit moet lezen krijgt die 4 adressen door. Als deze adressen 15, 12, 90, 33 zijn wordt dat doorgegeven.

[Verwijderd]

Tja misschien is een supercomputer niet meer dan een i7 zonder beveiliging.

[batjes]

ASLR has a very marginal impact on performance, while providing excellent
security benefits

ASLR Disabled ASLR Enabled Percent Change
Debian 25766ns 25780ns 0.01%
FreeBSD 79688ns 83031ns 4.20%
HardenedBSD 426399ns 435460ns 2.13%

(ik heb het geprobeerd te formateren )

https://www.google.nl/url...gQ&bvm=bv.135974163,d.d2s

Alhoewel dit op Debian en FreeBSD getest is, zal het ook op Windows bar weinig verschil uitmaken.

[Reactie gewijzigd door batjes op 23 juli 2024 15:56]

[CivLord]

De impact mag misschien marginaal zijn (al vind ik 4,2% niet echt marginaal meer), de verschillen vind ik schokkend!
Waarom heeft het op FreeBSD 420 keer meer impact dan op Debian? Het lijkt erop alsof er bij de implementatie in FreeBSD een paar flinke steken zijn laten vallen.

[batjes]

Dat zijn de BSD's.

Op Linux is de impact slechts 0.01%, op Windows is het vergelijkbaar.

[NESFreak]

Een kleine nuancering is natuurlijk als volgt: Dankzij aslr is het moeilijk om bij een bufferoverflow te bepalen waar de payload heen moet (omdat de kritieke code dus ergens 'random' staat). Voor dit om succesvol te zijn moet een bufferoverflow in een proces dus nog steeds mogelijk zijn.

ASLR is al een vorm van damage control, aangezien de mogelijkheid tot een bufferoverflow an sich al een bug is en een aanvaller dus toegang moet hebben tot software met de juiste rechten en met zo'n bug.

Helaas zie je toch nog te veel sprintf met user input voorbij komen die je er eigenlijk triviaal uit zou kunnen pakken (naast natuurlijk userinput naar array index operaties)...

[.oisyn]

ASLR is al een vorm van damage control, aangezien de mogelijkheid tot een bufferoverflow an sich al een bug is en een aanvaller dus toegang moet hebben tot software met de juiste rechten en met zo'n bug.

Dat is wat kort door de bocht. Er zijn in het verleden voldoende aanvallen geweest met speciaal geprepareerde .png en .jpg files, die door de decoding software niet goed worden afgehandeld. Serveer die op een webpagina en je hebt een aanval op de browser van de client.

[Reactie gewijzigd door .oisyn op 23 juli 2024 15:56]

[DarkScorpion]

Misschien dan toch maar ff een buffertje bijplaatsen. Knap gedaan, dat wel.

[.oisyn]

Hij heeft het iig duidelijk niet begrepen want wat hij zegt slaat nergens op