Onderzoekers misbruiken ddr3-lek vanuit webpagina

Onderzoekers zijn erin geslaagd om een bug in ddr3-geheugen te misbruiken met javascript. Daardoor kan een willekeurige webpagina bits flippen in het geheugen, zelfs als de browser in een sandbox draait en dat dus niet zou moeten kunnen.

De bug, die door Google-onderzoekers eerder Rowhammer is gedoopt, is niet nieuw, maar Oostenrijkse en Franse onderzoekers hebben nu een manier gevonden om de bug te exploiteren vanuit een website. Dat gebeurt door fysieke kwetsbaarheden in ddr3-geheugen te misbruiken.

De onderzoekers maakten een aanval die werkte op een systeem met Intel Haswell-processor, in een browser die javascript binnen een sandbox draait. Daarbij zou een aanvaller root-toegang tot een systeem kunnen krijgen, vermoeden de onderzoekers. De aanvallers wisten de bug in ieder geval in Firefox en Chrome te misbruiken.

Het probleem dat de onderzoekers aan de kaak stellen, bevindt zich in het fysieke ddr3-geheugen. Doordat geheugen op steeds kleinere schaal wordt gemaakt en geheugencellen zich steeds dichter bij elkaar bevinden, kan de elektrische lading van bits in het geheugen 'lekken' naar aangrenzende bits.

Dat dit kon, was al langer bekend, maar dat dat ook vanuit een webpagina zou kunnen, was nog niet eerder aangetoond. De kwetsbaarheid is in verschillende modellen ddr3-geheugen aanwezig, maar niet in al het geheugen: geheugen met error correcting code heeft er geen last van. Ook ddr4-geheugen is niet kwetsbaar. Het gaat daarbij vooralsnog enkel om pc's, maar de onderzoekers denken dat onderzoek naar telefoons nodig is, omdat die een variant op ddr3-geheugen bevatten.

Doordat het gaat om een fysieke kwetsbaarheid, werkt softwarematige beveiliging tegen aanvallen - zoals sandboxing en data execution prevention - niet meer. Daardoor kan een webpagina eigen code in het geheugen injecteren en die vervolgens uitvoeren. Dat is een zeer ernstige kwetsbaarheid, vooral omdat zij softwarematig niet is op te lossen. Alleen een bios-update zou nog enig soelaas kunnen bieden. Wel is het moeilijk om een concrete aanval te maken; hoewel bits flippen mogelijk is, moet dat namelijk ook nog eens in de goede volgorde gebeuren.

In dit specifieke geval is er wel een work-around die de impact zou kunnen beperken. Javascript zou langzamer kunnen draaien om het moeilijker te maken om de bug te misbruiken. Daarnaast raden de onderzoekers gebruikers aan om javascript uit te schakelen. Dat kan bijvoorbeeld via een extensie als NoScript.

Reacties (81)

[anargeek]

Hier is een voorbeeld te vinden van de javascript code. Het is niet heel ingewikkeld geschreven, dus dit valt makkelijk te verbergen in "normale" code.

Het advies om heel javascript te blokkeren gaat wel wat ver, aangezien de onderzoekers zelf ook niet weten hoe ze daadwerkelijk misbruik kunnen maken van deze bug.

[Mithrildor]

In dit voorbeeld schrijven ze alleen wat willekeurige bits naar een willekeurige locatie in het geheugen. Hiermee kun je best wat schade aanrichten, maar je verwachten dat malware wordt uitgevoerd als je het naar willekeurige locatie wegschrijft. Het zal veel moeilijker worden om met deze methode ook malware uit te voeren op een computer, je zult naar hele specifieke locaties moeten schrijven en door virtual memory kan dit overal in het fysieke geheugen zijn. Je zult waarschijnlijk dus van meerdere exploits gebruik moeten maken, en dan zul je veel meer code nodig hebben dan die 100 regels code die ze in dit voorbeeld gebruiken.

Overigens is het een enorm goed idee om javascript standaard uit te schakelen en alleen first party javascript code op vertrouwde websites toe te staan. Hierdoor kun je het grootste deel van de drive by downloads en andere aanvallen voorkomen. Dit is ook waarom adblockers het zo goed tegen malware doen; ze blokkeren onder andere de javascript code in advertenties.

[beascob]

Robert Graham zegt
Note that the hacker doesn't have complete control over which bits will be flipped. They are highly likely to flip the wrong bits and crash the system rather than gain exploitation. However, hackers have lots of ways of mitigating this. For example, as described in the google post, hackers can do a memory spray. They can allocate a large amount of memory, and then set it up so that no matter which bits gets flipped, the resulting value will still point to something valid.

The upshot is that while this problem seems random like cosmic rays, one should realize that hackers can control things better than it would appear. Historically, bugs like stack and heap overflows were once considered too random for hackers to predict, but which were then proven to be solidly predictable. Likewise, address space layout randomization was a technique design to stop hackers, which they then start using memory spray to defeat.
Je schiet dus met veel hagel en je weet niet waar het effect heeft?

[SkyStreaker]

Je schiet dus met veel hagel, wetende dat het uiteindelijk ergens effect heeft. Omdat je met genoeg schiet.

[Reactie gewijzigd door SkyStreaker op 2 augustus 2024 15:07]

[kimborntobewild]

Je schiet dus met veel hagel en je weet niet waar het effect heeft?

Ik denk dat je dit verkeerd begrijpt:

They can allocate a large amount of memory, and then set it up so that no matter which bits gets flipped, the resulting value will still point to something valid.

Stel, je hebt normaliter 2k nodig voor een stukje malware of code om (root) access te krijgen. Stel dat je niet een gericht bitje kan flippen, maar wel eentje (een willekeurige) in een 1k reeks.
Je hebt dan gewoon 2M i.p.v. 2k nodig voor het stukje malware. De commando's zitten niet netjes achter elkaar (met allemaal NOP of nullen ertussen waar de PC niks mee doet), maar dat hoeft waarschijnlijk ook niet als je op een bepaalde manier programmeert.

[MGutker]

Als je JavaScript blokkeerd werkt 60% van de websites op internet niet meer naar behoren. Wel weer jammer dat er ook nog steeds issues zijn met de beveiliging/functionaliteit van "basis" hardware, dan met name dat heel weinig mensen zich daar bewust van zijn.
Ik draai gelukkig DDR4 tegenwoordig

[Devaqto]

Dus er wordt aangeraden om Javascript uit te schakelen, dat betekent dat het web er niet meer uit ziet, althans voor mij.

Zou het geen mogelijkheid zijn om deze kwaadaardige Javascript code te filteren dmv een plugin of iets?

[CEx]

Waarschijnlijk niet, de bit flipping code kan verborgen worden in daadwerkelijk functionele stukken applicatie.
Zie het als verven van een kozijn (vullen specifieke geheugenadressen), je gaat er vanuit dat je alleen het hout verft, maar daarbij een stukje muur (aangrenzende adressen) meepakken kan gebeuren als je er geen voorzorgsmaatregelen zoals schilderstape (ECC) voor neemt.

[Blaise]

De exploit maakt gebruik van typed arrays. Misschien kan een plugin de ArrayBuffer functie overschrijven (ArrayBuffer = function(){ console.log('doet niet'); };) voordat JavaScript van een pagina wordt uitgevoerd. Dan werken alleen websites die gebruik maken van typed arrays niet meer, wat waarschijnlijk niet heel veel websites zijn.

[anargeek]

Waar heeft u dat gelezen? In de code op github wordt geen gebruikt gemaakt van ArrayBuffer. En als ik een exploit zou schrijven die bijv. ArrayBuffer gebruikt, zou ik zeker zelf een polyfill van ArrayBuffer erin stoppen

[Reactie gewijzigd door anargeek op 2 augustus 2024 15:07]

[Blaise]

Waar heeft u de code op github gevonden? Anyway, ik ging er van uit dat een typed array altijd een ArrayBuffer nodig heeft, en dan hoef je niet alle verschillende typed arrays te overschrijven of polyfillen. Maar het principe blijft gelden dat je de standaard functionaliteit van typed arrays verwijdert of vervangt in je browser zodat deze exploit niet meer werkt.

[guanche]

Nou het is niet bepaald een subtiel stukje code, dus browser bouwers kunnen er best op letten als je een Uint8ClampedArray(32*32*32*32*32*63) vol gaat rammen met een math.random functie. Toegegeven, de implementatie is natuurlijk makkelijk omgeschreven, maar het heet niet voor niets 'rowHammer'.

[Verwijderd]

Ze hebben het uitgetest door middel van Javascript, maar volgens mij moet het in theorie kunnen met vrijwel alles.
Ff heel beknopt naar de code gekeken.. lijkt mij dat dezelfde vorm van uitvoer vrijwel overal mogelijk is.

Volgens mij wordt er verder helemaal geen advies gegeven, omdat het een theoretische mogelijkheid is en niet eentje, die daadwerkelijk in de praktijk misbruikt wordt. (het is dus wel mogelijk al)
Dit lijkt mij een methode, waarvoor je behoorlijk veel tijd en energie moet steken om een exploit werkend te krijgen.

[robvanwijk]

Dus er wordt aangeraden om Javascript uit te schakelen, dat betekent dat het web er niet meer uit ziet, althans voor mij.

Als je JS letterlijk uitschakelt, dan zie ik je punt, maar als je het iets ruimer opvat en leest als "NoScript installeren" dan valt het reuze mee. Natuurlijk zijn er talloze sites die zonder JS niet fatsoenlijk werken, maar degene die je vaak gebruikt kun je gewoon (tijdelijk of permanent) whitelisten. Toegegeven, da's geen perfecte oplossing (als iemand jouw favoriete site kraakt en met hun JS rommelt, dan ben je nog steeds de sjaak) maar het maakt het risico wel vele malen kleiner; noem het een compromis tussen bruikbaarheid en veiligheid. (Er is overigens ook een gigantische hoeveelheid volkomen zinloze JS die overal en nergens dingen moet "opleuken", daar ben je dan ook meteen vanaf! )

Zou het geen mogelijkheid zijn om deze kwaadaardige Javascript code te filteren dmv een plugin of iets?

Dat noemen we een virusscanner... Leuk idee, maar die dingen lopen per definitie achter de feiten aan; je kunt niet scannen naar een virus (of, JS exploit code) dat nog niet geschreven is. Nee, ik denk dat NoScript (of iets dergelijks) veel practischer is.

[Brahiewahiewa]

Het gaat helemaal niet over Java script!
De onderzoekers hebben java script gebruikt, om aan te tonen dat deze techniek ook in een sandboxed omgeving succesvol te gebruiken is. Maar iedere andere vorm van uitvoerbare code kan dat net zo goed

[anargeek]

Toon mij een plugin die een stuk javascript code altijd blokkeert, en ik toon je 5 manieren om je code te herschrijven zodat het niet meer geblokkeerd kan worden

[Simyager]

Noscript?

[anargeek]

Hier ging het om een plugin die enkel kwaadaardige code blokkeert.

[Simyager]

Dat is wat Karizma zei,maar jij zei

Toon mij een plugin die een stuk javascript code altijd blokkeert

En die heet noscript
Maar je hebt gelijk dat er geen plugin bestaat die altijd kwaadaardige code tegen kan houden.

[maniak]

Zou je hiermee ook een host systeem kunnen overnemen in een virtual machine. Denk zelf aan bijvoorbeeld Azure of andere cloud diensten.

[maceddy2004]

Wanneer dat op Hyper-V of VMWare draait op serverhardware zal dat vermoedelijk ECC geheugen zijn en is dan dus niet kwetsbaar.

[maniak]

Ik had nog niet gedacht aan ECC geheugen al kan je het geheugen nog steeds zo flippen dat de ECC check nog steeds valide is. De check vindt immers pas plaats als dat deel van het geheugen uitgelezen wordt.

[Bas_B]

Maar om werkende code te injecteren die ook nog aan de ECC check zal voldoen grenst tegen het onmogelijke aan.

[TeleMax]

Voor een beetje assembly programmeur die de hele dag niets anders dan geheugentabellen in zijn hoofd is lijkt me het toch een haalbare uitdaging.. ECC doet toch alleen een pariteitsbitje zetten?

[guzzo]

Met 1 parity bit zou je alleen errors kunnen detecteren.
Bv, je zet de bit zodat de som van het aantal 1en in je data even is.

Stel je data bit is 1, dan is je parity ook 1, samen dus 11. Is de data 0, dan is de parity bit ook 0, samen 00.
Mocht er een bit geflipt worden en je had 11 kan het ecc mechanisme 10 of 01 lezen. Maar hoe moet het dan weten welk van de twee bits is geflipt? Het kan alleen zien dat er iets fout is gegaan (detection), maar ecc het Error Correcting Code. Als er meer databits zijn, 8 bv in een byte, wordt het alleen maar lastiger.
1 geflipte bit in mijn voorbeeld kan worden gecorrigeerd worden door nog een extra bit toe te voegen. Data bit 1 geeft dan bv 111 en data 0 geeft 000. Als dan 1 bit flipt kan het ecc aan de andere 2 bits zien wat hij had moeten zijn. Als er 2 bits omvallen gaat het weer mis, maar zulke codes kunnen altijd maar een beperkt aantal verkeerde bits detecteren en corrigeren.

In echte ecc worden ingewikkeldere codes gebruikt die op meer databits werken, maar ik weet zo niet welke. Ik kan me voorstellen dat er crc of hammingcodes worden gebruikt. Beiden zijn in de basis en voor kleine aantallen bits vrij eenvoudig en veel over te vinden op Wikipedia en google.

kennis van assembly gaat dus niet helpen bij het kraken van ecc. Beiden hebben weinig tot niets met elkaar te maken. Om de ecc te kraken moet een hacker precies de goede bits iig meerdere per byte) flippen, maar zoals het artikel al meld heeft een hacker hier weig controle over.

[Soldaatje]

Met virtuele systemen is het moeilijker de bug te misbruiken:

The hypervisor hosting virtual machines (VMs) use yet another layer of page tables. Unlike operating systems, hypervisors don't expose the physical mapping to the virtual machines. The upshot of this is that people running VMs in the cloud do not have to worry about other customers using this technique to hack them. It's probably not a concern anyway, since most cloud systems use error correcting memory, but the VM translation makes it extra hard to crack.
...
The biggest threat at the moment appears to be to desktops/laptops, because they have neither ECC memory nor virtual machines.

http://blog.erratasec.com...es-on-dram-rowhammer.html

[register]

Draaien er dan veel clouds zonder ECC geheugen?

[PolarBear]

Zou zo maar kunnen voor bepaalde toepassingen. Google gebruikt bijvoorbeeld goedkope hardware, is het stuk wordt het vervangen.

[NBK]

Voordeel van ECC is dat je merkt dat het stuk is. Normaal DDR heeft die check niet en geeft gewoon een blauw scherm als resultaat.
Maar inderdaad is het idee van veel goedkope hardware gebruiken in plaats van weinig dure speciale hardware een veel gebruikt principe.

[Reactie gewijzigd door NBK op 2 augustus 2024 15:07]

[Twazerty]

Of bestanden raken onherstelbaar beschadigd bij het verplaatsen/kopieren/uitpakken. Zo kwam ik er dus achter dat mijn geheugen defect was.

[MacD]

Wow.

Het enige welk helpt is dus je gehele pc vervangen, voor de meesten (ik inclusief), want ik draai nu ddr3 non-ec, en als ik dus ddr4 wil, moet ik m'n mobo upgraden ... en dus ook m'n cpu.

Dure grap, mobo+cpu+ram.

[CEx]

Error correcting modules erin...

[Niemand_Anders]

Veel consumenten moederborden hebben geen support voor ECC geheugen. Bij enkele (duurdere) moederborden kun je in sommige gevallen het geheugen zelf wel gebruiken, maar de ECC functionaliteit zelf wordt dan niet gebruikt. Het is ook mogelijk dat je moederbord het geheugen niet accepteerd en drie piepjes tijdens de POST test laat horen..

[CEx]

Goede aanvulling!
Na controle blijk ik hier ook geen gebruik van te kunnen maken.

[nhanssen]

Goeie marketing om achteraf pas onderzoek te doen, via angst ervoor zorgen dat mensen massaal nieuwe PC's gaan aanschaffen.

[mae-t.net]

Vooraf onderzoek doen naar een fout die nog gemaakt moet worden is in de praktijk een beetje lastig, lijkt me. Dan zou de hele fout er niet ingezeten hebben maar zouden we pas net van DDR2 af zijn.

[nhanssen]

Hmm dus als er een nieuwe snellere pacemaker op de markt zou komen zou je die dan niet eerst onderwerpen aan uitgebreide test? maar gewoon laten gebruiken door mensen? Dit is een ongemakkelijke vergelijking maar je snapt hem vast.

[mae-t.net]

Het lijkt mij dat DDR2 aan uitgebreide tests onderworpen is, en ik sluit ook zeker niet uit dat een snellere (? doet hij dan 300 bpm max inplaats van 200 ofzo?) pacemaker ook een onbekende bug heeft. Sterker nog, als ik me goed herinner zijn er wel degelijk ook kwetsbaarheden aangetroffen in implantaten.

Punt is, dat je een dergelijke bug ondanks testen, niet altijd binnen redelijke tijd en moeite opmerkt. Het is dus heel makkelijk om te zeggen dat je het dan maar vooraf moet testen.

Even om de gedachten te bepalen: DDR3 is ergens rond 2002 bedacht en in 2007 op de markt gekomen. 5 jaar ontwikkeling en nog eens bijna 8 jaar op de markt voordat de bug ontdekt is!

Met mijn opmerking in het voorgaande bericht bedoelde ik feitelijk twee dingen:
1) met vooraf testen wordt waarschijnlijk bedoeld of foutloos ontwerpen of tussen ontwerp en marktintroductie uitgebreider testen. Letterlijk vooraf testen kan niet omdat je dan nog geen idee hebt van het ontwerp dat je moet gaan testen.
2) de periode tussen ontwerp en marktintroductie is niet onbeperkt, dus een tamelijk obscure fout kun je niet atijd afvangen voordat iemand hem x jaar later alsnog ontdekt, tenzij de tests ook x jaar duren en/of door iemand met dezelfde gedachtenkronkel worden uitgevoerd. Het kan zomaar dat niemand de fout ooit had gevonden als het spul niet gewoon massaal op de markt was gekomen.

[Reactie gewijzigd door mae-t.net op 2 augustus 2024 15:07]

[Ge Someone]

Het "probleem" was er bij de introductie ook nog niet. Er wordt aangegeven dat het is ontstaan na het telkens kleiner maken van de geheugen-cellen.
Hier extra achtergrond informatie.

[Quilt]

ECC sowieso al een duurdere grap.

[Ro-Me]

Dit is hardwarematig in DDR3, ik vraag mij af hoe een BIOS-update hiertegen kan helpen.

[Caelestis]

Om een lang verhaal kort te maken met de bios update willen ze het verversing snelheid van de ram verdubbelen.

In het onderzoek hebben ze echter aan gegeven dat je minimaal 8 keer de snelheid nodig heb om nagenoeg onkwetsbaar te zijn dus is een bios update eigenlijk niet de oplossing.
Ter info: Hoe hoger het verversing snelheid hoe langzamer het geheugen wordt dus zie het niet als een positief oplossing of überhaupt iets voor langere duur.
Vandaar ook het idee om gewoon java zelf trager te maken zodat je het zelfde uitwerking krijgt maar zonder het geheugen te gimpen.

Waar ik zelf veel meer interesse in heb is of echt alle DDR3 geheugen hiervoor vatbaar is. Het Rowhammer attack wordt al een aardig tijd gebruikt door fabrikanten als een van de kwaliteit tests voor DDR3. In het onderzoek hebben ze de volgende machines getest
Lenovo T420 i5-2540M Sandy Bridge Corsair DDR3-1333 8 GB
Lenovo x230 i5-3320M Ivy Bridge Samsung DDR3-1600 4 GB (2×)
Asus H97-Pro i7-4790 Haswell Kingston DDR3-1600 8 GB

In alle gevallen worden standaard modules gebruikt die wel goed zijn maar niet extreem getest worden voor o.a overclocken. Ik ben echt benieuwd of een topsetje 2400+ mhz dominator modules net zo vatbaar zijn als die groene standaard dingen zonder heatsink.

[Ge Someone]

Java(script) is niet de enige manier om deze aanval te gebruiken, misschien wel een gevaarlijke.

[Caelestis]

Dat klopt maar op dit moment wel het enige mogelijkheid om het aanval via een standaard browser setup te laten lopen en dus op afstand uitgevoerd kan worden op niets vermoedend gebruikers.

[TimDJ]

Apple doet het door de memory refresh te versnellen. Daardoor is de attack blijkbaar moeilijker uit te voeren. https://support.apple.com/en-us/HT204934

Voor een overzicht van oplossingen en responses:
https://github.com/google.../docs/vendor_responses.md

[hoogevost]

"" De aanvallers wisten de bug in ieder geval in Firefox en Chrome te misbruiken."
Nou dat wordt dus IE of Safari en gone problem?

[cornedor]

Ik neem aan dat dit de browsers zijn waar zij het in hebben getest.

[hoogevost]

nou ja als ik lees 'hebben het in ieder geval daar weten te misbruiken' denk ik dat ze het wel in andere browsers getest hebben maar dat het daar is mislukt? of lees ik het dan verkeerd?

[cornedor]

Dat zou inderdaad een mogenlijkheid zijn. Maar er zit enorm veel verschil tussen de JavaScript engine van Firefox en die van Chrome, dus het lijk mij dat het ook mogenlijk is in IE en Safari.

[Ge Someone]

Het schijnt dat de Chrome ontwikkelaars hebben gereageerd met het niet langer toestaan van de CLFLUSH instructie, die nodig was voor de aanval. Maar dat sluit ander misbruik niet helemaal uit.

[i-chat]

valt dit niet op te lossen door heet ramgeheuge te scannen op code waardoor je zo'n exploit zou moeten herkennen, verder zou je natuurlijk tal van javascript features kunnen flaggen waarbij je virusscanner een waarschuwing geeft als er mogelijk gevaarlijke code zou worden uitgevoerd...

ik neem toch aan dat men redelijk in kan schatten hoe code er ongeveer uit zou moeten zien om dit te exploiten.

hoe zit dat trouwens met ecc, in het artiekel staat dat ecc hier iets tegen zou moeten kunnen doen, maar hoe zit dat eigenlijk met de ondersteuning van deze feature, in hedendaagse pc's kunnen cpus als een core i3 of een fusion a8 omgaan met dit soort geheuge.

[Reactie gewijzigd door i-chat op 2 augustus 2024 15:07]

[field33P]

De CPU wel, maar het moederbord vaak niet, puur om server features te limiteren aan duurdere borden. Hoewel i5 en i7s ook geen ECC hebben om de verkoop van Xeons te bevorderen.

[TERW_DAN]

Daarnaast raden de onderzoekers gebruikers aan om javascript uit te schakelen. Dat kan bijvoorbeeld via een extensie als NoScript.

Ja leuk, maar heel het web hangt tegenwoordig aan elkaar met JavaScript. Als je het uitzet mis je echt gigantisch veel functionaliteit, dus dat is ongeveer hetzelfde zeggen als dat je vooral geen websites moet bezoeken, behalve web1.0 sites

[Keypunchie]

De meeste exploits komen echter niet vanaf de site die je bezoekt, maar als drive-by via bijvoorbeeld een reclame. Door JavaScript alleen al voor 3e partijen uit te zetten, ben je al een stuk veiliger.

Draai zelf no-script en sta altijd het hoofddomein dat ik bezoek wel toe. Heb een whitelist om Content-Delivery domeinen toe te voegen

Het is wat bewerkelijk, maar voor mezelf een goeie balans tussen functionaliteit en privacy/security.

[Cyb]

Ik vraag me af of dit probleem nog breed in het algemene nieuws gaat komen. Als ik Google op "ddr3 geheugen misbruik" kom ik alleen Tweakers.net tegen.

Als ik het goed begrijp, zouden er miljoenen computers wereldwijd per direct hardwarematig vervangen/aangepast moeten worden (uitgaande dat er mee ge-internet dient te worden). Dat lijkt me toch wel wereldnieuws.

[Reactie gewijzigd door Cyb op 2 augustus 2024 15:07]

[Ge Someone]

probeer dan ook "kwetsbaarheid" ipv "misbruik".
Hier heb je al een hele goeie.

[Verwijderd]

Doordat het gaat om een fysieke kwetsbaarheid, werkt softwarematige beveiliging tegen aanvallen

Dat is natuurlijk niet per definitie het geval. Malware protection kan ook gebruik maken van het gedrag van kwaadaardige software, en dus ingrijpen als dergelijk gedrag (gedrag dat alleen bedoelt lijkt om aangrenzende geheugenposities te manipuleren) herkend wordt.