×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Onderzoekers omzeilen beveiligingsmaatregel door aanval op cpu

Door , 23 reacties

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.

Door Sander van Voorst

Nieuwsredacteur

19-10-2016 • 15:39

23 Linkedin Google+

Reacties (23)

Wijzig sortering
(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 19 oktober 2016 18:01]

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.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*