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
Maar met die methode haal je dus 1 van de 2 ontwikkelde timers weg en los je het probleem dus eigenlijk niet op. In IV. B staat namelijk: "SMC is agnostic to the quality of performance.now()
since it only relies on a separate observer core for its measure-
ments".

[Reactie gewijzigd door Vedette. op 16 februari 2017 08:08]

Klopt, als je je eigen timer ontwikkeld werkt mijn verdediging niet.

Maar de eigen timer is gebaserd op een aantal speciieke implementatie keuzes van SMC. Het idee dat je een eigen core krijgt is bijvoorbeeld geen garantie. Ook kan de core wijzigen - zeker in ARM big.LITTLE systemen of PC hypterthreads. En SMC is nog experimenteel en dus niet uitontwikkeld. Of de SMC timer zoals ontwikkeld dus ook zal blijven werken is maar de vraag. Standaard staat die feature bovendien niet aan op browsers, dus vandaag de dag is men wel degelijk afhankelijk van de performance.now().

Maar mijn punt was meer, dat de bedenkers zelf een zwak punt al aangeven. Ze moet een een timer hebben met weinig ruis, en geen drift. Daar kun je als browsermaker best op inhaken. Browser Javasctipt heeft namelijk normaal geen timer zonder drift nodig, en ook geen microseconde nauwkeurigheid.
Lijkt mij dat NoScript er juist voor zorgt dat de browser een stuk sneller wordt, want je hoeft 1. heel veel niet in te laden 2. heel veel niet uit te voeren.
Ja, en dus is de vraag waarom je vanuit die taal 'slim' variabelen kan lezen. Volgens mij kan dat alleen door bepaalde 'features' in js uit te buiten.
Zo lijkt het erop dat vanuit JS de resultaten van de MMU operaties benaderbaar zijn en dat had nooit gemogen.
Ik bedoel, jij hebt het over cachelines die verdwijnen, maar hoezo kan je vanuit JS bij die informatie komen?
Zoals het artikel aangeeft: de bevindingen zijn in oktober bekend gemaakt aan de hardware fabrikanten en browsermakers.

Het is dus niet zo dat ze dit gisteren gevonden hebben en vandaag met de wereld delen.

De redenen dat dit openbaar gemaakt zullen te maken hebben met
  • druk zetten op de betrokken partijen omdat de onderzoekers vinden dat dit zo snel mogelijk verholpen moet worden
  • gebruikers inlichten, zodat mensen zich bewust zijn van, niet alleen dat het probleem bestaat, maar ook dat de aanval gemakkelijk reproduceerbaar is.
Vaak wordt in zo'n disclosure besproken wat het termijn is waarin de onderzoekers het probleem geheimhouden. Openbaarmaking van deze informatie gebeurt over het algemeen achteraf, nadat het probleem verholpen is, of wanneer de onderzoekers het idee hebben dat ze niet serieus genomen worden.

[Reactie gewijzigd door Laloeka op 15 februari 2017 13:36]

"de bevindingen zijn in oktober bekend gemaakt aan de hardware fabrikanten en browsermakers.

Het is dus niet zo dat ze dit gisteren gevonden hebben en vandaag met de wereld delen."

Goed punt, en thx voor de aanvullende informatie hierover natuurlijk, altijd welkom.
Maar ze kunnen ze dit ook prima aan de partijen melden die hier wat aan mogen/kunnen gaan doen, en er zo zelf ook baat bij hebben, en het verder zolang stil houden, tot dat het is verholpen, en het dan pas aan het grote publiek melden.
Maar zoals het nu gaat, wordt het vaak eerst gemeld, en na de tijd pas opgelost.
Niet de meest slimme tactiek dus zeg maar (althans naar mijn idee dan) ;)

Edit: Typo's

[Reactie gewijzigd door SSDtje op 15 februari 2017 15:19]

Ze maken het bekend om prestige te winnen, kijk eens hoe goed onze faculteit is. En op die manier (mogelijk) ook aan meer fondsen en sponsering te komen.
Kijk, en dat wist ik dan weer niet.
Dus dat verklaart een hoop.
Thx voor het melden ;)

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

*