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

VU-onderzoekers omzeilen geheugenbescherming aslr via javascript

Door , 62 reacties

De onderzoeksgroep softwarebeveiliging van de VU, die onder leiding staat van professor Herbert Bos, heeft een aanval gepresenteerd waarmee de beveiligingsmaatregel aslr omzeild kan worden. Bescherming is vooralsnog niet mogelijk, omdat de aanval gebruikmaakt van een fundamentele eigenschap van processors.

De onderzoekers Ben Gras en Kaveh Razavi hebben de aanval de naam AnC gegeven. De side-channelaanval maakt gebruik van een fundamentele eigenschap van AMD-, Intel- en ARM-processors en vereist daarom geen lekken in software. De methode maakt gebruik van het feit dat de mmu van deze processors de cpu-cache gebruikt om page table walks uit te voeren, waarbij virtuele geheugenadressen worden omgezet in fysieke.

Gras legt aan Tweakers uit: "Dit onderzoek toont aan dat de resultaten van deze page table walks in de cpu-cache terechtkomen en daarom 'afgeluisterd' kunnen worden door, na de cache te manipuleren, te meten wanneer het opzoeken langzamer gaat. Denk aan een stethoscoop die je tegen een kluis aanduwt om te horen wat er binnen gebeurt." Deze aanval is zowel mogelijk vanuit Chrome als vanuit Firefox, toonden de onderzoekers aan.

Gras vervolgt: "Daardoor kan uitgerekend worden wat het adres is dat de mmu aan het opzoeken is, ook als dat in een domein gebeurt waarin die informatie beveiligingsgevoelig is en je het niet hoort te kunnen weten. We demonstreren dit in javascript in twee browsers en laten zien dat het verschijnsel op alle moderne Intel-, AMD- en ARM-modellen bestaat." De onderzoekers hebben de aanval op 22 verschillende processors getest en kwamen geen model tegen waarbij de methode niet werkte.

Door de methode toe te passen kan een aanvaller achter geheugenadressen komen, die normaal gesproken door aslr beschermd zouden moeten zijn. Deze techniek moet aanvallen op het systeemgeheugen, bijvoorbeeld stack overflows, moeilijker uitvoerbaar maken door willekeurige locaties in het virtuele geheugen aan te wijzen waar programma's belangrijke componenten kwijt kunnen. Volgens Gras is daarmee bijvoorbeeld aan de sandbox van javascript te ontkomen en zo code uit te voeren op het systeem van een slachtoffer, maar is er wel een tweede bug nodig om van een exploit te kunnen spreken. Deze methode gaat ervan uit dat de aanvaller javascriptcode kan uitvoeren in de browser, bijvoorbeeld door gebruik te maken van een kwaadaardige website.

Omdat de methode gebruikmaakt van een fundamentele processoreigenschap, is het vooralsnog niet mogelijk tegenmaatregelen te nemen. Het uitvoeren van javascriptcode kan wel worden tegengegaan, bijvoorbeeld door de Noscript-add-on te gebruiken, aldus de onderzoekers. Ze zijn in gesprek met zowel cpu-fabrikanten als browsermakers. Volgens Gras hebben de fabrikanten geen plannen bekendgemaakt om het probleem aan te pakken. Gras zegt dat het probleem op cpu-niveau op te lossen zou zijn door bijvoorbeeld een aparte mmu-cache te gebruiken. De onderzoekers hebben wel met Apple samengewerkt om WebKit van aanvullende beveiliging te voorzien.

De onderzoeksgroep heeft het disclosure-proces, dat gecoördineerd wordt door het NCSC, in oktober in gang gezet. Er zijn verschillende kenmerken in het leven geroepen. Zo geldt CVE-2017-5925 voor Intel-processors, CVE-2017-5926 voor AMD en CVE-2017-5927 voor ARM. De benaderde browsermakers, Apple, Mozilla, Google en Microsoft, maken gebruik van CVE-2017-5928. De presentatie van de methode vindt plaats op het NDSS-symposium, dat eind deze maand in de VS plaatsvindt.

Demonstratie van de aanval in Firefox

Sander van Voorst

Nieuwsredacteur

15 februari 2017 00:01

62 reacties

Linkedin Google+

Reacties (62)

Wijzig sortering
Een direct gevaar is er niet, maar het is makkelijker om adressen te achterhalen van functies en dus makkelijk exploits te maken voor systemen met aslr. Bij systemen zonder aslr kon dit gewoon altijd al. Stel de functie voor het starten van een command prompt staat normaalgeproken op 0x123456 maar als je aslr gebruikt kan het overal staan. Je kan in dat geval niet zeggen start de functie op 0x123456 omdat je niet weet waar het staat. Met deze methode kan je het adres achterhalen en alsnog de functie starten. Je hebt uiteraard wel een andere exploit nodig om de functie te starten.

Dit is puur aslr omzeilen en niets anders, het is dus niet zo dat alle machines in 1x kwetsbaar zijn. Je kan er geen code mee uitvoeren of data aanpassen wat je normaalgesproken niet mag. Het is een beetje zoals het zonder aslr was, waarmee we al jaren hebben gedraaid zonder dat iemand zich hier druk over maakte. Wat ik eerder bizar vind is dat dit werkt via javascript ;)
Nog meer Jip-en-Janneke taal:

Om code uit te voeren waartoe je geen rechten hebt, moet je drie dingen doen:

1) Zorg dat de code ergens in het geheugen staat
2) Weet waar het in het geheugen staat
3) Zorg dat de processor naar de plek in het geheugen springt waar de code staat

1) Is het makkelijkst, dat kan met JavaScript. 3) Is moeilijk, maar in het verleden zijn vaak beveiligingsgaten gevonden waarmee het mogelijk is. Blijft 2) over, waar bovenstaande techniek over gaat.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel XL 2 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

*