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 tonen Rowhammer-aanval om browser over te nemen op Android-toestel

Onderzoekers van de VUSec-onderzoeksgroep van de Vrije Universiteit in Amsterdam hebben een proof of concept van een Rowhammer-aanval getoond, waarmee ze code binnen de browser op een Android-toestel kunnen uitvoeren. De aanval richt zich op de gpu en gebruikt JavaScript.

De onderzoekers hebben hun onderzoek gepubliceerd onder de naam GLitch, als verwijzing naar de WebGL-api die toegang geeft tot de gpu. Een van de onderzoekers, Pietro Frigo, legt aan Wired uit dat ze zich op de gpu van mobiele socs richten en dat deze in ander onderzoek werd genegeerd. Toch zou deze zich lenen voor het uitvoeren van een Rowhammer-aanval, waarbij de onderzoekers uiteindelijk in staat waren om op afstand code uit te voeren in de Firefox-browser op onder meer een Nexus 5-smartphone. Vooralsnog is hun exploit alleen voor deze browser geschikt†en voor de Snapdragon 800- en 801-socs van Qualcomm, die gebruikmaken van de Adreno 330-gpu. Het slachtoffer hoeft alleen een kwaadaardige WebGL-pagina te bezoeken, waarna de aanval ongeveer twee minuten in beslag neemt.

Een Rowhammer-aanval draait om het flippen†van bits, bijvoorbeeld van 0 naar 1 en andersom. De aanval werkt door†snel achter elkaar bepaalde geheugenrijen te activeren, waardoor de staat van een cel verandert†en de flip plaatsvindt. Door dit verschijnsel gericht in te zetten, kunnen aanvallers bepaalde veranderingen in het geheugen teweegbrengen die uiteindelijk toegang geven tot het systeem. In dit geval kregen de onderzoekers toegang tot de browser, maar niet tot het onderliggende Android-systeem. Hoewel de aanval nu beperkt is tot oudere telefoons en Firefox, zou het ook mogelijk zijn om nieuwere toestellen en andere browsers aan te vallen, aldus Frigo.

Zowel Google als Mozilla reageerde†tegenover Wired op de bevindingen. Google stelt dat het geen aanval is die een risico vormt voor het overgrote deel van zijn gebruikers. Zo zouden kwaadaardige apps van buiten de Play Store een veel groter risico vormen. Het bedrijf stelt verder dat de aanval een stuk lastiger is op nieuwere toestellen, waar de onderzoekers tegenover stellen dat ze ook†bit flips†konden veroorzaken op een Pixel-telefoon. Er is echter nog geen volledig functionele aanval. Google heeft alsnog wijzigingen in Chrome aangebracht die dit soort aanvallen moeten voorkomen. De patch is op 13 maart uitgebracht.

Mozilla stelt dat het in de laatste Firefox-release al een wijziging heeft aangebracht die een aanval als GLitch moet bemoeilijken, en dat het aanvullende beschermingsmaatregelen introduceert in versie 60 van Firefox, die op 9 mei uitkomt. Frigo legt uit dat een aanval ook bemoeilijkt kan worden door de wijze aan te passen waarop WebGL toegang heeft tot het geheugen van een apparaat. Nieuwer geheugen, zoals ddr4, zou bovendien aanvullende bescherming bieden. Al maakte dat in het geval van de Pixel niet uit.

In eerder onderzoek toonden wetenschappers van dezelfde onderzoeksgroep aan dat een Rowhammer-aanval mogelijk was op Android-toestellen door gebruik te maken van een kwaadaardige app. Deze methode noemden ze Drammer. De onderzoeksgroep houdt zich al langer bezig met dit soort aanvallen, zoals Flip Feng Shui.

Demonstratie van GLitch (muziekwaarschuwing)

Door Sander van Voorst

Nieuwsredacteur

03-05-2018 • 14:57

33 Linkedin Google+

Reacties (33)

Wijzig sortering
Google stelt dat het geen aanval is die een risico vormt voor het overgrote deel van zijn gebruikers.
Dit kom op mij over alsof Google de boel echt niet serieus neemt. Onbegrijpelijk.
Dit kom op mij over alsof Google de boel echt niet serieus neemt. Onbegrijpelijk.
Er is heel veel dat je over Google kan zeggen, maar niet dat ze security in zijn algemeen niet serieus nemen.

Daarvoor zijn ze te veel een drijvende kracht achter security initiatieven als Project Zero, het bevorderen van SSL en zaken als Safe Browsing.

Google investeert veel in White Hat activiteiten.

Laten ze dan nooit steken vallen? Tuurlijk wel. Ook bij Google zijn ze menselijk en kennen ze limieten of economische belangen.

Zo hadden ze de fragmentatie op Android kunnen zien aankomen en de bijbehorende veiligheidsproblemen (tegenwoordig is daar een project voor, maar Google had m.i. meer kunnen doen). Ook is Project Zero soms iets te scheutig met het publiceren van kwetsbaarheden. Ook niet per se wenselijk.

Dus ja, wellicht onderschatten ze Rowhammer in dit geval. Maar over het algemeen weten ze bij Google verdomd goed waar ze het over hebben op security gebied.
Je hebt helemaal gelijk. Google - en elke andere softwarefabrikant - zit hier in een moeilijke positie. Je kunt hier namelijk geen patch voor uitbrengen: Rowhammer is een hardwarebug.

Het 'voordeel' is dat Rowhammer extreem afhankelijk is van je geheugenlayout. Hoewel deze bug ongetwijfeld te exploiten is op elk systeem met DDR3 of DDR4-geheugen (ja dit gaat ook werken op iOS als je lang genoeg probeert), moet je voor elk systeem je parameters tweaken afhankelijk van hoe de CPU en software je geheugen inrichten. Op dit moment lijkt het daarom alsof Rowhammer alleen ingezet kan worden voor heel getargete aanvallen.

Dit kan pas worden 'gepatcht' met nieuwe hardware. Fixes moeten worden opgenomen in de DDR5-standaard. Ook gebruik van ECC op DDR3 en DDR4 maakt deze aanvallen een stuk moeilijker (maar niet onmogelijk).
Je kunt wel een patch uitbrengen voor "rowhammer vanuit de browser". De browser is namelijk software.
Triviaal: je XOR'ed alle Javascript geheugen access met een pseudo-random byte stream die per geladen webpagina verschilt. Er zijn ongetwijfeld effectievere methoden, maar dit bewijst al dat het in software te fixen is.
Je kan wel degelijk een software patch uitbrengen voor deze bug. Dat staat zelfs letterlijk zo beschreven in het artikel en ook dat Google dit al in Chrome heeft gedaan..
Dat heeft het artikel dan niet helemaal juist beschreven. Een software-oplossing bestaat niet voor hoe Rowhammer. Je kan het hoogstens met wat truukjes wat moeilijker maken - en dat heeft Google dan waarschijnlijk gedaan.
Dit kan pas worden 'gepatcht' met nieuwe hardware. Fixes moeten worden opgenomen in de DDR5-standaard. Ook gebruik van ECC op DDR3 en DDR4 maakt deze aanvallen een stuk moeilijker (maar niet onmogelijk).
Niet per se, maar dat hangt erg van je hardware af. Het zou wellicht mogelijk zijn om met een firmware update de refresh rate van je geheugencontroller op te schroeven, wat je wat performance zal kosten maar wel beter tegen Rowhammer beschermt.

Overigens moet ik nog steeds een bewijs/PoC zien waarbij een systeem met ECC aantoonbaar kwetsbaar is hiervoor; ECC is juist ontworpen om dergelijke bitflips te detecteren/corrigeren (afhankelijk van hoeveel bits geflipped zijn), dus je zal eerder een denial of service krijgen omdat bepaalde software stopt met werken door te hoge ECC error rates, dan dat je dit succesvol kan gebruiken als exploit op een ECC systeem.

Ik vermoed dat de beste oplossing uiteindelijk meer slimmigheid in de geheugencontrollers zal zijn door gebruik te maken van dynamische refresh, wat beter bijhoudt welke DRAM rows een refresh nodig hebben (bijvoorbeeld omdat een naburige row veelvuldig geschreven is). Dit, in combinatie met ECC, lijkt me een behoorlijk degelijke oplossing tegen Rowhammer. Ik vraag me af of we ECC zullen gaan zien in de mobiele markt, want tot nu toe wordt het altijd 'te duur' geacht.
Wat je quote is niks meer dan een constatering. Nergens staat dat ze het niet erg vinden of helemaal niks mee gaan doen. Enkel dat er dingen zijn met hogere prioriteiten omdat de potentiŽle gevolgen daarvan groter zijn. Klinkt mij juist als doordacht en wel serieus dus :)
Tweakers schrijft niet over een specifieke Android versie, waarschijnlijk is dat wel het geval.
Ik snap je punt, maar deze opmerking "Zo zouden kwaadaardige apps van buiten de Play Store een veel groter risico vormen." vond ik veel kwalijker.

Het is het alsof iemand zegt dat roken slecht is en Google vervolgens zegt "Ja, maar alcohol is nog veel slechter!"

Anyway... Google en Security zit vaak wel goed hoor.
Omdat:
Hoewel de aanval nu beperkt is tot oudere telefoons en Firefox, zou het ook mogelijk zijn om nieuwere toestellen en andere browsers aan te vallen, aldus Frigo.
Jammer alleen dat ik NoScript gebruik, dus dat gaat ze niet lukken.
Je bent met NoScript net zo goed vatbaar. Als het script bij wijze van op raw.github.com of gist.github.com staat en jij die domeinen whitelisted hebt, ben je alsnog vatbaar. ;)

Ben zelf intussen afgestapt van NoScript, omdat het mij meer in de weg stond dan dat het echt nuttig was.

[Reactie gewijzigd door CH4OS op 3 mei 2018 17:56]

Dat snap ik niet helemaal: als jij naar raw.github.com gaat, dan wordt er in jouw browser toch geen code uit het repository uitgevoerd? De enige code die uitgevoerd wordt is de code van Github zelf. De code uit het repository wordt toch alleen getoond, niet uitgevoerd.
Als een pagina (vb. Mijnsite.com)deze code bevat <script src=//raw.github.com> wordt de code van github wel uitgevoerd. Als betwijfel ik of de uitzondering raw.github.com globaal geld, want dat betekent dat 1 domein met ad uitzondering, alle ads op andere sites doorlaat.

[Reactie gewijzigd door JeroenED op 3 mei 2018 23:20]

Jij whitelist ongetwijfeld bepaalde domeinen (op zijn minst Tweakers.net, anders kun je niet eens reageren hier).

Als zo'n domein gecompromitteerd raakt en de javascript serveert, dan kun je nog steeds het haasje zijn.

NoScript goeie zaak (draai het ook), maar maakt je niet volledig immuun!
Android is geen windows, dat schijnen veel mensen hier nogal eens te vergeten. Een exploit waarmee je de browser kunt overnemen heeft maar zeer beperkte gevolgen, eigenlijk alleen voor de browser zelf. Je kunt er geen generieke root methode mee bouwen of zo.
Ik weet niet waarom je dat zegt, want juist in Windows is de browser al sinds jaar en dag afgescheiden van de rest. IN eerste instantie met schediing van het UI en render process, waarbij deie laatste in lagere prioriteit draaide, en sinds Windows 8.1 in echte sandboxen. En zo draait Edge tegenwoordig zelfs in een in een dubbele eigen app-chamber. Enzo heeft Chrome ook zijn eigen afgeschermde omgeving.

Android de browser heeft inmiddels afhankelijk van de permissies meer bevoegdheden dan de Edge browser in Windows heeft. Kijk maar eens naar de permissies die die standaard heeft bij de meest gangbare browsers.

Dus ja, inbreken in de browser is wellicht geen root-access, maar minstens net zo serieus als een exploit in Firefox, Edge of Chrome.
op een Android-toestel
Gelukkig dat iedereen zelfde toestel, inwendige hardware en software versies gebruikt.
Inderdaad een bijzondere keuze om dit op Android te proberen. Op apple hardware heeft het veel meer potentie.
Het marktaandeel Android is veel groter en andere browsers op Apple iDevices gebruiken onderhuids Safari/Webkit, dus de kans dat zoiets werkt op Apple is veel kleiner juist.
Als het dan werkt met Safari werkt het meteen met alle browsers.
Er zijn alleen al van Samsung hi-end toestellen sinds S7 een Europese versie met Samsung cpu en Amerikaanse met Qualcomm cpu... om maar te zwijgen over andere afwijken en van verschillende software versies..

Het was sarcasme...
En inderdaad exploit op een Apple aan de praat krijgen heeft veel meer succes potentie.
Los jij zo alle problemen op je werk op als systeem en netwerkbeheerder? "Oh installeer toch dit gewoon en het is verholpen." Tot de volgende ontdekking/probleem op "dit" en wat ga je dan doen? Terug naar "dit" of ontwikkel je "dat" misschien om "dit" op te lossen?
Inderdaad een bijzonder uitgangspunt gezien zijn functie. Zou het bijzonder vinden als ik van software pakket moet wisselen omdat er een bug in de ander zit. Lijkt me in een beetje bedrijf ook een grotere taak om data te migreren van een systeem naar een ander dan om de bug te fixen.
Ga jij je eens heel snel inlezen over hoe rowhammer werkt voordat je zulke comments achter laat. In theorie heb je om het te misbruiken niets anders nodig dan voorspelbaare geheugenmanipulatie met een redelijk hoge doorvoersnelheid. WebGL is hoogstwaarschijnlijk een haalbare aanvalsvector voor rowhammer in elke mobiele en niet mobiele browser. Op de desktop is javascript eigenlijk al voldoende.
pas als ALLE browsers een risico vormen lijkt me het een wat groter probleem, nu is het zo'n kleine groep die er mogelijk last van krijgt...en wat simpel te verhelpen is door Chrome te installeren!
Tuurlijk, ongeveer 170 miljoen mensen (en stijgend), waar maken we ons nu allemaal druk over?

Weet je heel zeker dat je netwerkbeheerder bent?
Ik weet nou niet of dit de juiste insteek is van iemand die zijn geld verdiend met beheer. Nu is het nog geen probleem. Wat als het opeens wel een probleem is en het komt niet naar buiten?
Dat is iets te kort door de bocht... Geef mij 1 vinger en ik pak je hele hand. Zo werkt het ook met exploits. Vaak is het een opstapje naar meer.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True