Onderzoekers tonen ddr-kwetsbaarheid RAMBleed op basis van Rowhammer

Onderzoekers hebben een lek ontdekt waarmee data uit het werkgeheugen van een computer kan worden uitgelezen. Het lek krijgt de naam RAMBleed en is gebaseerd op de Rowhammer-kwetsbaarheid.

RAMbleed werd ontdekt door onderzoekers van de Universiteit van Graz in Oostenrijk, de Universiteit van Michigan, en de Universiteit van Adelaide. De onderzoekers wisten de aanval te gebruiken om een OpenSSH-sleutel met een RSA-2048-algoritme van een server uit te lezen.

Het lek werkt op dezelfde manier als Rowhammer, een ram-lek uit 2015 waarbij de ruimte tussen fysieke bits in het werkgeheugen kan worden gemanipuleerd. RAMBleed maakt gebruik van die kwetsbaarheid. Het grote verschil is dat de data alleen af te lezen is, maar niet te manipuleren. Bij de aanval wordt gebruik gemaakt van bit flipping, een proces waarbij een cryptografische sleutel wordt uitgelezen door de veranderingen in bits uit te lezen. Het lek zou ook werken op geheugen dat gebruik maakt van error code correction, dat normaal gesproken gebruikt wordt om bit flips te corrigeren.

De onderzoekers publiceerden een proof-of-concept op ddr3-geheugen, maar zeggen dat de kwetsbaarheid ook in ddr4-geheugen kan worden uitgebuit. In het verleden zijn er al bit flipping-aanvallen op ddr4 uitgevoerd.

Reacties (29)

Om het artikel maar even aan te vullen en te nuanceren:

Users can mitigate their risk by upgrading their memory to DDR4 with targeted row refresh (TRR) enabled. While Rowhammer-induced bit flips have been demonstrated on TRR, it is harder to accomplish in practice.

Wel met de volgende twee kanttekeningen:

- TRR is geen standaard en wordt op veel verschillende manieren geïmplementeerd door vendors en het is dus gevaarlijk te vertrouwen op claims gemaakt over TRR door de vendors

- Effectiviteit van TRR is afhankelijk van de geometrie van het geheugen en de snelheid waarop het geheugen loopt. TRR is alleen "bewezen" als oplossing op de laagste DDR-4 snelheid

Hmm dus in de praktijk heb je hier weinig aan, als gewone gebruiker?

Als het goed geïmplementeerd is en de controller genoeg capaciteit heeft, is het mogelijk een oplossing. Het probleem is dus alleen dat op dit moment je de vendor op zijn woord moet geloven dat hun implementatie werkt en ook bij alle snelheden en die-sizes (DDR4 gebakken op, bijvoorbeeld, 7nm is mogelijk met een identieke controller wel vatbaar, terwijl geheugen gebakken op 14nm dat niet is)

Vergeet ook niet de belangrijkste kanttekening dat je al je ram daarvoor moet vervangen...

Amd ryzen pro, thread ripper en Epycs kunnen hun eigen geheugen encripten op hardware nivo aes 128 bit. Hier door wordt row hammer nutteloos, ze kunnen een bit flippen ja, maar wat die bit doet dat weten ze dan niet en het geheugen uit lezen is ook zin loos dus dan hoef je geen nieuwe ram te kopen.

Volgens missen een aantal delen die wel relevant zijn:

- Het werkt op ECC omdat er een side-channel is die door timing kan vaststellen of ECC de bit gecorrigeerd heeft. Komt de bit meteen binnen: was de originele waarde. Komt de bit na "lange" tijd binnen dan was de bit origineel omgekeerd.

- Vanwege bepaalde eigenschappen die een cryptografische sleutel moet hebben hoef je niet alle bits van een sleutel te achterhalen. (ongeveer 30% is voldoende, 80% is ideaal)

- De aanval heeft een opzetperiode (tenminste momenteel) van meer dan 30 uur. Hoewel de aanval dus effectief is is het mogelijk, als je de opzetperiode kan voorkomen, om via simpele software aanpassingen de aanval een stuk minder effectief te maken.

[Reactie gewijzigd door Belgar op 13 juni 2019 12:17]

Een server is toch vaak meer dan 30u achter elkaar aan? Hoe kan je de opzetperiode in dat geval voorkomen?

De opzetperiode is nodig om de sleutel naar geheugenplaatsen te manoeuvreren welke vatbaar zijn voor de aanval.

betere memory layout randomisation (ook voor bepaalde userspace delen) zou kunnen helpen. memory migration van processen. Enclave's gebaseerd op user/security settings. Experts weten waarschijnlijk nog veel meer potentiële oplossingen. Zolang de sleutel niet ge-sandwich-ed kan worden tussen geheugenplaatsen beheerd door de aanvaller kan de aanval niet plaatsvinden.

Je kunt ook gewoon heel simpel je geheugen encripten, AMD ryzen pro, thread ripper en Epycs ondersteunen het. Dit wordt hardware matig gedaan door de geheugencontroller, ook al flippen ze een bit ze weten nooit wat ze aan het doen zijn, en geheugen uitlezen... Succes met 128bit aes encryption...

Je zou (afhankelijk van je applicatie) meerdere servers met een automatische failover kunnen gebruiken zodat je je iedere server binnen zeg 24 uur opnieuw opstart.

Bitflips horen normaliter toch nooit voor te mogen komen? Dit lijkt een sidechannel wat werkt door gebruik te maken van geheugen dat niet aan de specificaties voldoet (Random Access Memory moet je immers toch random kunnen benaderen/bewerken?). Ga je bijvoorbeeld overklokken of aan de timings rommelen zodat deze buiten specificatie vallen dan zou ik dit soort bit-flips wel verwachten.
Zeker bij servergeheugen zijn bitflips ronduit gevaarlijk voor de data en draaiende software.

offtopic:
Overigens is die Rowhammer misschien wel handig om slecht geheugen te identificaren.

Bitflips horen niet voor te komen, maar het gebeurt wel. Dat is waarom enterprise land extra geld uit geeft aan ECC ram.

En volgens het artikel kun je dit dus ook op ECC RAM misbruiken.

Dat komt doordat ECC memory bitflips niet voorkomt maar geneest, lees verder maar de comment van @Belgar voor meer detail. Dit is overigens weinig relevant is voor de comment waar we hier origineel op reageren.

Het gaat hier om side-channel aanvallen waarbij dingen juist buiten de specs om worden gedaan.

Bitflips kunnen ook optreden door externe invloeden. Kosmische straling bijvoorbeeld. Dat is bijvoorbeeld een zorg bij vliegtuigen (hoe hoger in de atmosfeer, hoe meer straling) en natuurlijk helemaal in ruimtevaart

Rowhammer is feitelijk een ontwerpfout. Het product wordt gebruikt volgens specificatie en toch treden er heel veel geheugenfouten op. In geen enkele fabrikant zijn productdocumentatie staat dat het geheugentoegangspatroon van rowhammer op de een of andere manier bijzonder is en extreem veel fouten veroorzaakt.

Wikipedia heeft hier een aardig stukje over geheugenfouten. Wat daar ook opvalt:
- een gigantische variatie in de error rates. 7(!) ordes van grootte. De ene DRAM is de andere niet.
- Praktijkmetingen bij Google die veel hogere error-rates aangeven dan bij voorgaande laboratorium test.

Jammer dat hardware sites geheugen niet massaal op error rates (=kwaliteit) testen. De meeste komen niet verder dan kijken hoever ze het geheugen kunnen overklokken, zonder dat er overduidelijke fouten optreden, en wat dat met de framerates van spelletjes doet.

Als we ff opschieten met dat optische RAM dan zal dit denk ik ook onmogelijk gemaakt worden.

Waar een deur sluit, gaat een andere open. Dan zit je weer met een andere kwetsbaarheid.

Of andersom: Als een deur dicht zit is het altijd wel voor iemand interessant of uitdagend om die deur toch open te maken.

Prima als ze dit soort veiligheidsproblemen oplossen, maar als hiermee pcs nog een keer 25-30% langzamer worden in prestaties, begint het irritant te worden.

Voor jouw en mijn PCtje zijn dit typisch lekken die niet zo interessant zijn, maar als jij een Apple/Facebook/Google/ASML/Overheid bent is dit wel degelijk een dingetje als een stukje software je geheugen 'at random' kan uitlezen.

Het zou toch vervelend zijn als de root-certificates van een één of andere grote CA in verkeerde handen komen (diginotar), dus dat een willekeurige nepsite in eens een geldig certificaat voor google.com of digid.nl in handen krijgt, door (zwaar gechargeerd) simpelweg een stukje RAM uit te lezen.

Uiteraard zijn er nogal wat voorwaardes, maar als je echt heel erg graag wilt als NSA georganiseerde misdaad dan krijg je dat best wel voor elkaar.

Wacht, je stelt voor om de schuld van hardwarebugs bij software te leggen en vervolgens meld je trots dat je je systeemsoftware niet up to date houdt.
Volgens mij ben je een beetje in de war...

erh een beetje wow je statement...

Ik heb de presentatie van rowhammer (met een in depth uitleg) gezien en zou je toch aanraden dat ook te doen voor je met zo een niet-onderbouwde claims komt.

Ze lieten daar vrij duidelijk zien dat het rowhammerprincipe dreef op in feite crappy / goedkope hardware. Bij verschillende tests op verschillende (destijds) telefoons zag je ook dat sommige fabrikanten hun spul wel in orde hadden en andere weer niet.

Het patchen is lang niet zo simpel als wat jij even roept: ik ben namelijk effectief het geheugen aan het manipuleren. Waar jij denkt naar https://<genericOSname>.<domain>/<updates> te gaan, manipuleer ik je geheugen waardoor je naar https://<asfsgener1csadfsdfsOSname>.<domain>/<updates> gaat (een domein wat ik 'toevallig' ook geregistreerd heb staan). Als ik zover ben, kan ik opeens gigantisch veel

Bedenk ook even alle spinoffs/varianten die er op rowhammer zijn gekomen al. Het is dus meer dan een hardwarehack, het toont een vrij significant issue aan, wat nu al wat jaren op rij issues blijft scoren.

Wat je claim mbt. patchen is / dat je een windows 7 sp1 image draait, geen idee wat je daarmee duidelijk probeert te maken, buiten dat je met een n=1 anekdotisch bewijs komt. Ik kan je namelijk garanderen dat als je laatste patch van 2011-ish is, dat je binnen 5 minuten slachtoffer bent van een hack mocht je interessant genoeg worden bevonden daarvoor Jezelf dus niet te hard op de schouders kloppen als de realiteit is dat je waarschijnlijk gewoon niet interessant genoeg bent.