VUSec-onderzoekers weten ecc-geheugen aan te vallen met Rowhammer

Onderzoekers van de Vrije Universiteit Amsterdam zijn erin geslaagd succesvolle Rowhammer-aanvallen uit te voeren op ecc-geheugen. Tot nu toe werd gedacht dat error correcting code beschermde tegen Rowhammer.

De onderzoekers van VUSec, dat zich bij de VU op beveiliging richt, hebben hun methode ECCploit genoemd en de details over hun bevindingen in een overzicht gepubliceerd. Hun onderzoek begon met de vraag in hoeverre ecc daadwerkelijk beschermt tegen Rowhammer.

In 2015 verscheen Rowhammer: een manier om hammering van geheugencellen te misbruiken. Bij hammering weten onderzoekers een bit van 0 naar 1 of omgekeerd te flippen, door een bit op een andere locatie aan een groot aantal lees- en schrijfacties te onderwerpen. De aanval bleek op meerdere typen dram toe te passen en pc's, smartphones, virtuele machines en meer systemen waren er kwetsbaar voor. Bovendien verschenen er meerdere manieren om de aanvallen uit te voeren, waaronder via JavaScript.

Tot nu toe was de gedachte dat error correcting code beschermde tegen Rowhammer-aanvallen. Ecc-geheugen is dram voor zakelijke doeleinden, dat bescherming biedt tegen datacorruptie. Het geheugen kan flips van een enkele bit detecteren en corrigeren. Dit werkt door middel van 'woorden' van bijvoorbeeld 64 bits, met redundante controle-bits naast de data-bits. Ecc moet zo bescherming bieden tegen bitflips die veroorzaakt kunnen worden door achtergrondstraling, maar leek zo ook te beschermen tegen Rowhammer.

De VUSec-onderzoekers schrijven dat ecc ook twee bitflips per woord kan detecteren, maar dan code laat crashen. Om ecc te omzeilen zijn dus minimaal drie specifieke bitflips nodig, maar dat moet zo gebeuren dat niet eerst twee bitflips plaatsvinden, om een crash te voorkomen. Het onderzoeksteam nam een jaar de tijd om ecc-implementaties te ontleden. "Dit deel van het werk was gekkigheid, met ingevroren geheugenchips voor cold boot-aanvallen en injectienaalden die in geheugensockets gestoken werden om errors te veroorzaken", schrijven ze.

Op basis van hun experimenten slaagden ze erin gecontroleerd meerdere bitflip-pogingen binnen een ecc-woord op hetzelfde moment uit te voeren. Ook bedachten ze een manier om te detecteren welke bit het ecc corrigeerde, door middel van een timing side channel. Ze ondervonden namelijk dat het langer duurde om een locatie uit te lezen waar een bitflip gecorrigeerd was. Tenslotte moesten ze woorden vinden met drie bits die vatbaar waren om te flippen, zodat ze met één keer hameren die drie bits konden flippen en de ecc-bescherming konden omzeilen voor een geslaagde Rowhammer-aanval.

De onderzoekers gebruikten ddr3-geheugen van verschillende fabrikanten, maar denken dat de side channel-aanval ook bij ddr4 werkt. De aanval is ook op afstand uit te voeren, mits de aanvaller genoeg informatie heeft over de ecc-engine. Het team heeft de publicatie gecoördineerd met het Nederlandse NCSC en de volgnummers CVE-2018-18904, CVE-2018-18905 en CVE-2018-18906 zijn aan de kwetsbaarheden gehangen. Ze beschrijven de details in een draftpublicatie met de titel Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks.

Reacties (20)

[StackMySwitchUp]

Ik vind als managed hosting systeembeheerder moeilijk in te schatten wat nu het effect/de impact is en waar ik me tegen moet wapenen om hier niet vatbaar voor te zijn. Niet gehinderd door verdere kennis over dit onderwerp, vraag ik daarom: heeft iemand hier meer informatie over?

[burne]

De grote vraag is of jij bepaalt welke code er op jouw CPU draait. Als jij de enige gebruiker van een system bent heb je niets te vrezen. Rowhammer en neefjes worden pas eng als iemand anders ook code op dezelfde CPU kan draaien. In de praktijk: een VPS of VM in een gedeelde omgeving, of Javascript in je browser.

[Cerberus_tm]

Al moet Javascript meen ik wel extreem precies tijden kunnen aflezen om zo'n aanval uit te kunnen voeren (net als bij Spectre e.d.). Volgens mij hebben de grote browsers al wel wat bescherming tegen dat misbruik van tijdsuitlezing ingebouwd; maar je kunt geloof ik ook de meest precies manier van uitlezen uitzetten in Firefox (dat was een work-around voordat Firefox tegen Spectre had gepatch). Ik neem aan dat dat nog steeds kan, en ik vermoed dat deze aanval dan niet meer mogelijk is via de browser (behalve misschien met Flash o.i.d.). Mozilla zegt bijvoorbeeld, bij de Javascript-functie performance.now():

The performance.now() method returns a DOMHighResTimeStamp, measured in milliseconds.

The timestamp is not actually high-resolution. To mitigate security threats such as Spectre, browsers currently round the results to varying degrees. (Firefox started rounding to 1 millisecond in Firefox 60.) Some browsers may also slightly randomize the timestamp. The precision may improve again in future releases; browser developers are still investigating these timing attacks and how best to mitigate them.

— https://developer.mozilla...s/Web/API/Performance/now

Reduced time precision

To offer protection against timing attacks and fingerprinting, the precision of time stamps might get rounded depending on browser settings.
In Firefox, the privacy.reduceTimerPrecision preference is enabled by default and defaults to 20us in Firefox 59; in 60 it will be 2ms.
...
In Firefox, you can also enabled privacy.resistFingerprinting, the precision will be 100ms or the value of privacy.resistFingerprinting.reduceTimerPrecision.microseconds, whichever is larger.

— https://developer.mozilla...b/API/DOMHighResTimeStamp

Overigens leek het erop dat DDR4 minder kwetsbaar is dan DDR3, maar de onderzoekers zeggen blijkbaar dat het misschien ook kan met DDR4. Uit ouder onderzoek bleek dat SK Hynix (en in mindere mate Samsung) chips voor DDR4 maakten die misschien niet kwetsbaar waren, terwijl die van Micron dat potentieel wel waren; zie deze vraag op Stack Exchange van enige tijd geleden:
https://security.stackexc...mputer-against-row-hammer

Dat ECC niet noodzakelijkerwijs beschermt tegen Rowhammer was ook al langer bekend (zie ook link).

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 08:05]

[StackMySwitchUp]

Dit is tot nu toe het enige nuttige antwoord op mijn vraag. Bedankt
Hoe het zit met de kosten/baten voor security is niet interessant, dat moet ik dagelijks aan klanten uitleggen.

[TStick]

Managed hosting. Hoe vaak komt dat nog voor dat je bij zo'n oplossing dedicated machines hebt ? Ik ben geen kenner, maar is virtualisatie niet de norm bij managed hosting oplossingen ?

[fastbikkel]

Hebben jullie een security afdeling? Zo ja, mooi.
Zo niet, dan zou ik aandacht vragen bij de leiding en wellicht een externe partij erbij halen.
Ik denk dat het wel meevalt met het gevaar, maar hoeveel willen jullie afdekken?

[Ayporos]

Precies dit.

Security is een afweging van risico/kosten/baten.
Hoeveel (financieel) risico loop je? Hoe groot is de kans dat zo'n aanval op jou systemen zou kunnen plaatsvinden? Hoe groot is de impact als zo'n aanval slaagt? (ben je een bank of ben je een forum met file-sharing voor particulieren? heb je backups? hoeveel downtime kan je veroorloven om backups terug te zetten?)
Wat gaat het je kosten om je te wapenen? Wat voor soorten van bewapening zou je kunnen toepassen, wat kost dat, en welke zijn het wel of niet waard gezien de omvang van je bedrijf en geldstromen?

100% veiligheid bestaat niet. Wat wél kan is weloverwogen risico mindering en spreiding tegen een acceptabele prijs met een eventueel risico dat lijdbaar is.

Zie het zo:
Je kunt als particulier investeren in een hardware firewall van grofweg duizend euro, je kunt een modem/router/switch netwerksetup kopen van een paar duizend euro, je kunt software firewalls installeren en je kunt een systeem administrator inhuren om de PC van je dochter te monitoren en beschermen en managen.... óf je kunt een dagelijkse/weekelijkse backup van haar PC maken naar een NAS/externe schijf en gewoon de PC wipen wanneer er een virus op komt.

Zoals ik altijd zeg, het is altijd een afweging. Veiligheid vs bruikbaarheid vs kost.
Als we allemaal altijd voor maximale veiligheid gingen dan bestonden messen niet en zou je op elke weg maar 5km/u mogen rijden met je auto.

[deneys]

"Tenslotte moesten ze woorden vinden met drie bits die vatbaar waren om te flippen"

Klinkt alsof ze het random kunnen doen, dus een gerichte aanval lijkt moeilijk?

[SKiLLa]

Klinkt moeilijk, maar dat zei men ook over DEP bypasses middels ROP-chaining. Dat is in de praktijk toch veel realistischer gebleken dan men dacht. Een soortgelijke complexiteit/limitatie geldt hier ook, er zijn iets meer randvoorwaarden, maar nog steeds mogelijkheden genoeg. Denk aan bijvoorbeeld aan scenario's waar 1-bit flippen voldoende is (klassieke Rowhammer payloads) en de overige 2 bits 'collateral damage' niet de aanval verstoren.

Soms zijn omliggende bits in de datastructuur ook op een andere manier te beïnvloeden (side-channel attack) en zodanig 'te prepareren'. Of je hamert eerst omliggende bits om die in een gewenste positie te krijgen voor de daadwerkelijke aanval, ala het oplossen van een Rubiks-cube.

Neem het versimpelde voorbeeld dat je uid=0 wilt worden (privilege execution middels code execution) en dat je de beheer-datastructuur van je eigen proces in geheugen kunt hameren (TEB in Windows, TCB in Linux). uid=0 ben je niet, [1, 6] werkt niet zomaar en 7 is meteen succesvolle aanval. 1/7 success-rate is niet slecht, met een beetje geluk ben je er na 3 of 4 proces-starts al. Nu lopen de uids natuurlijk niet van 0 tot slechts 7, maar misschien was uid=1 ook een priviliged account; of kun je het proces-id van je thread zetten naar die van een priviliged proces (kunnen er een dozijn+ zijn) of je hijacked juist een bestaande thread-id uit een ander proces. Veel opties waaruit je slechts 1 match nodig hebt (en ik met slechts tot de TEB/TCB beperkt heb).

[peschinl]

gefeliciteerd, je leest gegevens uit een module van je pc. waarom is dit een security issue? sinds je toegang hebt tot het moederbord is everything up for grabs.

[SKiLLa]

Nee, die fysieke toegang was alleen nodig voor het reverse-engineeren van de werking van de ECC. Eenmaal ontdekt, is de aanval (zelfs op afstand in theorie) via software uit te voeren (zonder fysieke toegang tot hardware).

[Jaap-Jan]

Voor de aanval zelf is geen fysieke toegang nodig. Dat was alleen nodig om de werking van ECC- geheugen te doorgronden. Dus het is wel degelijk een security issue.

[flippy]

en wat is nu daadwerkelijk mogelijk met deze techniek?

[nopcode]

De Rowhammer aanvallen hebben een impact op de integriteit van het (D)RAM geheugen.
Met deze side-channel aanval kan eender welk proces (in zeer beperkte mate) het geheugen van andere processen aanpassen.

Op het vlak van exploits is Rowhammer niet anders dan andere memory read/write vulnerabilities: sandbox escapes (zelfs vanuit javascript op een webpagina in een browser), volledige memory dumps door processen die niet als root/admin draaien, privilege escalation naar root (bv ook op android), ...

Nu blijkt zelfs dat ECC DRAM ons niet kan beschermen van de Rowhammer.

[Stoney3K]

Nu blijkt zelfs dat ECC DRAM ons niet kan beschermen van de Rowhammer.

Een volledige fail-safe beveiliging ga je (op consumenten- of zakelijke systemen) toch niet krijgen, want beschermingsmechanismen zoals ECC zijn gemaakt om willekeurige fouten en defecten op te vangen, niet om te beschermen tegen moedwillige sabotage.

Daardoor maakt ECC het niet onmogelijk, maar wel moeilijker om aanvallen zoals Rowhammer uit te voeren, en duurt het aanvallen langer, waardoor er misschien meer tijd is om te detecteren dat iemand op je geheugen zit te hameren... vergelijk het met een inbreker die nu een half uur aan een slot moet gaan morrelen en niet meer een bankpasje tussen de deurpost kan schuiven. Dan is het risico dat je als aanvaller opgemerkt wordt een heel stuk groter.

Als je echt sabotage-bestendig wil werken dan ga je naar luchtvaart-principes toe: Bijvoorbeeld twee onafhankelijke CPUs en twee sets geheugen die elkaar controleren, liefst nog ontwikkeld door twee verschillende fabrikanten. Dan is de kans dat een fout gelijktijdig bij allebei de geheugens of CPUs optreedt, verwaarloosbaar klein geworden.

[job_h]

Korte Internet search op rowhammer:
https://googleprojectzero...owhammer-bug-to-gain.html

De titel van die publicatie van het Google Zero team is "Exploiting the DRAM rowhammer bug to gain kernel privileges". Dat zal voldoende info zijn om aan te tonen dat dit ernstig is, maar lees gerust de hele tekst als je het interessant vindt

tl;dr: Een normale applicatie die opeens zelf admin rechten kan krijgen via deze bug is niet de bedoeling

[Rudie_V]

Eerst dan nog op DDR4 met 8-bit ECC proberen. Maar bij DDR5 kan men ook 16-bit ECC gebruiken, dat zal nog wel moeilijker worden dan.
https://nl.hardware.info/...ecc-getoond-door-sk-hynix

[burne]

Da's niet relevant. DDR5 heeft (soms) meer bits voor ECC omdat de bus ook dubbel mag zijn (2 x 32bits+8bits ECC)

[Noxious]

Ze ondervonden namelijk dat het langer duurde om een locatie uit te lezen waar een bitflip gecorrigeerd was.

Houd dit ook in dat het in theorie makkelijker is om ECC op deze manier te beïnvloeden? Dit geeft namelijk een extra mogelijkheid tot verificatie.

[veltnet]

Hier een filmpje waarin het probleem (rowhammer) wordt gedemonstreerd

https://www.youtube.com/watch?v=-JXZbGj0kFc