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 ;)
Wat ik eerder bizar vind is dat dit werkt via javascript ;)

Precies dat is dan ook het meest nieuwswaardige. Imers zo vinden de meeste besmettingen van PC's plaats.

Maar de onderzoekers geven zelf al wat tegenmiddelen. Zo melden ze dat het bewust invoegen van ruis in de JavaScript timer hun aanval al moeilijker maakt.

Verder vraag ik me persoonlijk af, waarom Javascript toegang moet hebben tot eigenschappen van het cache (al dan niet direct of indirect via uitlezen van CPU type) zoals associativiteit en soort instructie-cache. Zonder die data wordt het moeilijker om aan de hand van cache timings, te weten welke instructies wel niet gecached worden en zo indirect adresinformatie te verzamelen.
Je hebt gelijk, ik leg mijn punt dan ook slordig uit. Wat ik bedoelde is dat afleidend uit hun onderzoek je wat tegenmiddelen kunt geven. Zelf spreken ze van reductie van nauwkeurigheid. Ik dacht zelf aan het invoegen van ruis in de JavaScript timer. Liefst non-random ruis, en eentje met een kleine bias. Specifiek IV.A wordt hiermee namelijk voorkomen

"We, however, believe that TTT can also be used in performance.now() with
jitter as long as it does not drift, but it will require a higher
number of measurements to combat jitter
."

Mijn doel was om bewuste drif te introduceren. Maar zelfs als dat niet kan om compatibiliteitsredenen, het gaat uiteindelijk om de tijdsduur waarin een aanval mogelijk is. Mijn hoop is dat het lang genoeg gemaakt kan worden.

Het grootste zwakke punt van deze aanval is echter dat het behoorlijk gedetaileerde info over het cache moet hebben, welke normaal niet te krijgen is. Toch is dat natuurlijk niet helemaal geruststellend.
Als je toegang hebt heb je niks aan deze javascript exploit.

Deze javascript exploit is een "tool" om die toegang te krijgen met je huidige exploit.

Ik kan niet geloven dat ik op Tweakers zie hoe zwaar deze bug onderschat wordt. Dat je een +3 hebt voor deze reactie vind ik echt zeer zorgwekkend.
Niks persoonlijks, trouwens.

Maar er zijn nu technieken om DEP te omzeilen, sandboxes te omzeilen en nu aslr die je b.v. "ff" de return address voor je BOF exploit stuurt terwijl dit voor veel exploits onmogelijk/moeilijk was.

Om even op erwin80 te reageren:

Ik vind het vertrouwen van de vendor van de software die we gebruiken "zoals in de goede oude dagen" geen goed idee en we hebben genoeg voorbeelden van hoe gevaarlijk deze situatie is. (Adobe Flash Player anyone?) .

We hadden vroeger ook de CLSID-bug waarmee je even een clsid kon plakken als extensie en je heel makkelijk van je virus een "jpeg-bestand" of "mp3-bestand" te maken die dan uitvoerbaar was.

Of de Ping of Death op Windows 95.

Ik snap niet dat we bijna juichen dat we terug in de tijd gaan met onze beveiliging. Vooral niet wanneer er nu al zoveel gevaar is voor besmettingen van b.v. ransomware en wanneer malware / spyware steeds hardnekkiger en ingewikkelder wordt.
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.
Dit is misschien wel het ergste lek van het afgelopen jaar. Juist doordat het hardwarematig is.

Valt wel mee, want het "lek" is niet nieuw, maar al eerder aangetoond. Nieuwe hier is dat het in Javascript gebeurde.

Maar het is ook geen lek in zichzelf. Het is een methode om informatie over te ontdekken waar bepaalde bibliotheekcode geladen is, die je zelf ook kunt aanroepen.

Het gevaar zit hem erin dat je het physieke adres kunt ontdekken, hetgeen mogelijk bruikbaar is in een andere aanval, zoals een use-after-free, waarbij een ander hoger gepriviliceerd process (buiten de Javascript sandbox) nu weet waar deze handige bibliotheekfuncties zitten. Dat maakt het voor die andere aanvallen aanzienlijk makkelijker.

Er zitten echter nog wel wat haken en ogen aan een echte end-to-end aanval, maar het is wel een knappe doorontwikkeling van hun onderzoek van vorig jaar.
Je browser up-to-date houden is waarschijnlijk al voldoende. De browser is op beveiligingsgebied waarschijnlijk het meest onderzochte stuk software op je pc, dus de kans dat je via javascript aan code-injectie kunt doen lijkt me klein, en zonder deze tweede zwakheid kan je met het gevonden adres alsnog niets.
Virtual machines hebben meestal geen toegang tot hardwareversnelling voor het decoderen van video en het versnellen van graphics. Daarom moet alles op de CPU gebeuren. Als je PC op de achtergrond ergens mee bezig is of als je een video bekijkt dan kan dit voor traagheid zorgen. Hardwareversnelling in virtual machines komt wel steeds vaker voor maar de meeste consumentenoplossingen kunnen dit vaak niet zo goed.

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

*