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 ontwikkelen exploit voor elke Android-smartphone met lpddr-geheugen

Acht onderzoekers, waarvan drie van de Vrije Universiteit in Amsterdam, hebben de proof-of-concept RAMpage onthuld, waarmee ze Android-smartphones kunnen overnemen. Met RAMpage borduren ze voort op Rowhammer.

De RAMpage-exploit treft elke Android-smartphone met lpddr-geheugen, waarmee in feite elk toestel met het OS sinds 2012 vatbaar is, beschrijven de onderzoekers op de speciaal voor de publicatie aangemaakte RAMpage-site. De onderzoekers hebben de proof-of-concept op een LG G4 met Android 7.1.1 getest, maar ze gaan ervan uit dat het op overige toestellen ook werkt. De methode zou zelfs op desktopsystemen kunnen werken. De onderzoekers noemen dit 'heel waarschijnlijk'. De kwetsbaarheid heeft aanduiding CVE-2018-9442 gekregen en is erkend door Google.

RAMpage ramt in de woorden van de onderzoekers de geheugenpages om willekeurige lees- en schrijftoegang te verkrijgen. De onderzoekers ontwikkelden RAMpage als onderdeel van hun onderzoek naar de effectiviteit van de oplossingen die zijn ontwikkeld tegen Rowhammer, de in 2015 bekendgemaakte aanval die werkt door snel achter elkaar bepaalde geheugenrijen te activeren, waardoor een aanvaller in staat is om bits te flippen. Volgens de onderzoekers zijn de oplossingen tegen Rowhammer ontoereikend en met name de Drammer-aanval uit 2016 is nog steeds reden tot zorg. Drammer was een Rowhammer-aanval, specifiek gericht op mobiele platformen.

Om Drammer-aanvallen tegen te gaan, wijzigde Google functionaliteit in het ION-subsysteem van Android. Dit subsysteem zit sinds Android 4.0 in het besturingssysteem en zorgt voor de geheugenallocatie van geopende applicaties. Google schakelde contiguous memory allocations uit als bescherming tegen Drammer, maar de onderzoekers beschrijven in hun rapport vier RAMpage-aanvallen op ION om aan te tonen dat de bescherming onvoldoende is en via het geheugen nog steeds het gehele systeem over te nemen is.

De onderzoekers hebben zelf software ontwikkeld die betere bescherming biedt, met de naam GuardION. Dit werkt door het begin en eind van niet-gealloceerde geheugenbuffers te isoleren. Volgens Google zorgt GuardION wel voor overhead die de prestaties negatief be´nvloedt bij applicaties. De onderzoekers werken samen met Google om dit te verbeteren.

De bevindingen staan beschreven in het document GuardION: Practical Mitigation of DMA-based Rowhammer Attacks on ARM. Het onderzoek is verricht door teams van de Universiteit Amsterdam, de Indiase Amrita University de Amerikaanse UC Santa Barbara en het Franse Eurecom. Van de VU was onder andere beveiligingsonderzoeker Herbert Bos betrokken, die ook verantwoordelijk was voor Drammer.

Door Olaf van Miltenburg

Nieuwsco÷rdinator

28-06-2018 • 22:01

28 Linkedin Google+

Submitter: Danny.G

Reacties (28)

Wijzig sortering
Aangezien Apple dit type geheugen ook gebruikt, waarom is iOS dan niet vatbaar?

Update: Als ik een andere bron over deze exploit lees, hebben de onderzoekers het er over dat het zou kunnen werken op iOS, macOS, Windows PCs en zelfs cloud servers.

[Reactie gewijzigd door RebelwaClue op 28 juni 2018 22:12]

Het gaat om een variatie van de al bekende Rowhammer exploit welke werkt op bijna alle apparaten met DRAM geheugen. Hier de abstract van het werk.

https://vvdveen.com/publications/dimva2018.pdf
we present
rampage
, a set of DMA-based Rowhammer at-
tacks against the latest Android OS, consisting of (1) a root exploit, and
(2) a series of app-to-app exploit scenarios that bypass all defenses.
Er wordt niet veel specifieke informatie gegeven, maar zoals ik het lees hebben de onderzoekers Google's mechanisme om te beschermen tegen Rowhammer aanvallen onder de loep genomen en er wat gaten in geprikt.

In theorie zijn andere apparaten ook kwetsbaar, maar omdat elke fabrikant zijn eigen vorm van detectie en bescherming heeft ingebouwd zal het op elk platform anders zijn.
The exploitation steps for
rampage r0
now involve the following sequence:
1. Exhaust ION memory page pools.
2. Monitor
/proc/pagetypeinfo
and allocate chunks using ION’s
SYSTEM
heap
with large orders that span at least 3 or more physical rows, e.g., chunks of
at least 256 KB if the row size is 64 KB. As soon as ION’s internal pools
are drained, we will see each of these large order allocations immediately
affecting
pagetypeinfo
. From this point, each subsequent request for (large)
ION chunks is likely to be contiguous as they are being served by buddy
directly.
3. Optionally, to confirm that allocated chunks are contiguous, we could either
(1) perform double-sided Rowhammer to check if there are any flips, or (2)
use the bank-conflict side-channel [12].
4. Template the memory using double-sided Rowhammer to find an exploitable
page.
5. Perform
Phys Feng Shui
so that the large chunk that contains the vulnerable
page is split in multiple smaller chunks (of the row size) that we can release
individually [28].
6. Confirm that the aggressor rows are still accessible by performing a second
templating round.
7. Release the vulnerable row. This will give it back to the ION cache.
8. Perform a
cache pool shrink
operation. This will release memory from all
registered shrinkers—including the ION cache—back to buddy.
9. Perform page table spraying while monitoring
/proc/pagetypeinfo
until
the first chunk of the row size is touched.
10. Allocate page tables until all chunks of the row size are used.
Once page tables using row size chunks are allocated, we could set those page
tables with values that point it back to itself when hammered. Once we are able
to get access to the page table, we scan the kernel memory for
struct cred
bytes and overwrite the UID’s to that of root.
Deze zelfde stappen zou je in theorie ook toe kunnen passen op een iOS apparaat met hetzelfde als gevolg.

Daarbij moet wel even worden gezegd dat het ook afhankelijk is van het merk. Samsung en Micron hebben een stukje techniek welke Targeted Row Refresh (TRR) heet ingebouwd, komt erop neer dat de chip vanzelf de rij boven en onder refreshed. De chips van Samsung zijn sowieso kwalitatief veel beter en hebben in de praktijk bijna geen last van dit fenomeen. Chips van Elpida zijn kwalitatief veel minder en hebben hier sterk last van. De onderzoekers noemen dit ook in hun bastract.
even though newer standards
such as LPDDR4 [18] discuss the adoption of Rowhammer mitigations, i.e., Tar-
get Row Refresh (TRR), they do so only as an
optional
protection mechanism,
thus making LPDDR4 chips vulnerable as well [20, 28].
Alhoewel ik niet zo goed gebrijp wat ze nou hiermee bedoelen. TRR is niet een onderdeel van de standaard, ik denk dat ze dat ermee bedoelen. Alleen Samsung en Micron gebruiken het.

Apple neemt zijn geheugen af bij Samsung, SK Hynix en Toshiba (bestaat niet meer) dus het is ook afwachten wat er in jou apparaat zit.

[Reactie gewijzigd door SizzLorr op 29 juni 2018 04:41]

ik heb een presentatie mogen bijwonen van 1 van de onderzoekers: van wat ik van hem begreep is het een hardwareissues, waardoor de software eigenlijk niet meer relevant is. Het speelde vooral bij goedkopere types geheugen (in de zaal natuurlijk meteen getest op eigen telefoons, die van mijn broertje crashte instant bij het zoeken naar 'bitflips', mijn samsung boeide het heel erg weinig, een collega van me had vrij rap al prijs).

De kans is vrij aanwezig dat Apple een betere kwaliteit memory gebruikt en hierdoor minder dat issue heeft (en het dus ook minder interessant is als proof of concept).
[..] Rowhammer, de in 2015 bekendgemaakte aanval die werkt door snel achter elkaar bepaalde geheugenrijen te activeren, waardoor een aanvaller in staat is om bits te flippen.
Dit klinkt als een kwetsbaarheid in de hardware zelf.... weet iemand hoe dat zit?
Om Drammer-aanvallen tegen te gaan, wijzigde Google functionaliteit in het ION-subsysteem van Android.
En dit klinkt alsof het OS een workround rondom de hardware kwetsbaarheid heeft opgenomen...

Ik heb het artikel nu 2 keer gelezen maar het wordt me niet duidelijk of dit nu klopt of niet.
Klopt dat dit een hardware fout is in de geheugen chips. Door het snel overschrijven van hetzelfde geheugengebied, kan in een aangrenzend geheugen gebied soms onbedoeld een bit flippen (een 0 wordt een 1 of omgekeerd). Voor zover ik weet duurt het uitvoeren van een succesvolle rawhammer aanval vele uren.

Als je ECC geheugen hebt, dan werkt rawhammer niet; omdat dit soort geheugenmodules error correctie heeft. Het dure ECC geheugen vind je normaal gesproken alleen in servers (of bij tweakers ;) ).
Rowhammer? ECC is absoluut geen garantie dat je dan veilig bent bij die aanval!
Zie http://www.thirdio.com/rowhammer.pdf en https://arstechnica.com/i...-vulnerable-to-rowhammer/
Resistent tegen een echte aanval ben je met ECC wel, maar blijkbaar zorgt het er voor dat je server met ECC spontaan reboot of uitvalt.

Source: In de PDF en artikel die je gelinkt hebt geven beide reboots en power-offs aan m.b.t. ECC geheugen.

[Reactie gewijzigd door NotCYF op 29 juni 2018 21:24]

/Offtopic
Die afbeelding van je zou verboden moeten worden :+
Wat (voor zover ik kon vinden) wel helpt is als je DDR4-chips gemaakt zijn door Samsung: die had zo weinig bitflips dat in elk geval die vorige aanval niet werkte. Ook de chips van SK Hynix hadden zo weinig bitflips dat het bijna onmogelijk leek. Die van Crucial hadden wel genoeg bitflips. Het is alleen super lastig om uit te vinden door wie de chips op een willekeurig reepje RAM gemaakt zijn.

[Reactie gewijzigd door Cerberus_tm op 29 juni 2018 01:31]

Nouja met deze exploit heb je meteen een manier om uit te vinden of die RAM gemaakt is door ofwel Samsung of SK Hynix ofwel een andere fabrikant ;)
Haha, heel fijn. Maar dat ging eigenlijk over gewone DDR4 voor in de computer, dus geldt wellicht niet voor dit.
Moet wel nuances in aangebracht worden, het probleem zit heel anders in elkaar. ECC is nooit bedoeld als security check, het is bedoeld als bescherming tegen data verlies. Als we het hebben over ECC dan moeten we ook de vraag stellen: "welke ECC?" want er zijn meerdere algoritmes die worden gebruikt door meerdere fabrikanten.

De goedkopere DDR3 implementaties waren zeker kwetsbaar, dit kwam omdat ze niet op elke operatie werkten (alleen op refresh) en ze correctable errors maskeerde en niet doorgaven aan het OS. In de tussentijd kon je eem rowhammer aanval toepassen zonder dat het OS ervan wist.

In DDR4 wordt er niks meer gemaskeerd en wordt alles aan het OS doorgegeven.

Daar zit dan nog een ander probleem. Het OS doet er verder niks mee, het wordt in de logs opgenomen en klaar. In het ergste geval gooit je server er een triple reset tegenaan en gaat hij lekker opnieuw opstarten.

Met DDR4 zijn fabrikanten bewust geworden van dit probleem en zijn ze andere algoritmes gaan gebruiken welke niet meer kwetsbaar zijn voor een dergelijk aanval, maar dan blijft je nog steeds zitten met het probleem van je OS. Het wordt gelogd, admin denkt oh dit reepje heeft veel fouten dus het zal wel aan het einde van zn leven zijn en vervangt het, dat er een mogelijke aanval is dat kan je niet zomaar opmaken uit de informatie die op dat moment beschikbaar is.
https://youtu.be/-JXZbGj0kFc

Dit is de presentatie die op sha2017 gegeven werd. Mogelijk biedt het wat aanvulling op tekst.
Als er door snel achter elkaar bepaalde geheugenrijen te activeren bits flippen is het geheugen toch zowiezo niet consistent?! Of doen ze dit boven de maximale adresbussnelheid?
Het probleem is dat, door de manier waarop het geheugen werkt, aangrenzende geheugenrijen soms worden aangetast. Row hammer.
Als je het mij vraagt is dan het geheugen niet consistent en dus eigenlijk buiten specificatie, RAM = random access memory: dat moet niet ineens vergeetachtig worden van bepaalde patronen ;)
Je hebt wel gelijk, alleen is het een al lang bekend feit dat bepaalde soorten RAM dit defect hebben. In principe komt een gebruikspatroon dat dit scenario triggert nooit voor, dus het hoeft geen probleem te zijn. Alleen blijkt dus dat slim misbruik van dit defect security implicaties heeft. Rowhammer was daar (bij mijn weten) de eerste in, en die techniek wordt nu steeds verder uitgedacht.

ECC RAM heeft dit overigens niet, dus servers zijn niet vatbaar voor deze categorie aanvallen.
ECC maakt het moeilijker, maar niet onmogelijk. ECC vermindert wel de impact aanzienlijk, een systeem met ECC iets anders laten doen dan alleen maar crashen is schier onmogelijk.
I stand corrected, dank voor deze aanvulling :)
Hier de app even geprobeerd op m'n Galaxy s8 met de laatste security patch: instant reboot wanneer ik in de app op hammertime druk.
Same here. Wellicht beveiliging tegen het overnemen van je telefoon
Ik was wel benieuwd naar de tests, dus ook de app eens geprobeerd. Op een OnePlus 5T met de laatste Beta update blijft alles groen, dus neem aan dat het dan niet vatbaar is? Op de meest aggresieve mode stopt Android de app wel, maar op 95% en minder draaide ik de tests een paar keer achter elkaar en lijkt er geen probleem.
Wat me verbaast, want het artikel doet erger vermoeden. Zijn er mensen die wel kwetsbaar zijn?
Moest effe lachen op hun website:

What is guardions of the galaxy?
That would be our guardion defense deployed on any Samsung model.
Hier op Nokia 8 met 8.1.0 niks, try to free more ram or reboot and try again.
Op mijn Mix 2 met Miui 9.5 totaal geen probleem _/-\o_
Toch mooi dat een webpagina die gaat over exploits op een mobile device voor geen meter schaalt op een mobiele browser :+
Xiaomi Redmi Note 3 Pro (kate) met nitrogenOS 8.1 en ook totaal nergens problemen mee.
Loopt gewoon vrolijk te zoeken naar bitflips, maar vind ze niet.

EDIT:
Ook op de meest aggressive stand nergens last van.

Voor de ge´nteresseerden.. de app staat op hun site.
https://vvdveen.com/drammer.apk

[Reactie gewijzigd door HellStorm666 op 29 juni 2018 08:36]

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S10 Google Pixel 3

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