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]

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

*