Onderzoekers presenteren exploit die geen lek in software nodig heeft

Beveiligingsonderzoeker Herbert Bos, verbonden aan de VU, heeft met zijn onderzoeksgroep een aanval ontwikkeld die niet gebruikmaakt van bugs in software. Deze komt deels voort uit tekortkomingen van dram-geheugen en staat bijvoorbeeld het achterhalen van wachtwoorden toe.

Ook heeft de aanval tot gevolg dat veel systemen van eindgebruikers kwetsbaar zijn. De hoogleraar systeem- en netwerkbeveiliging demonstreerde de techniek op een Windows 10-machine met de nieuwste versie van de Edge-browser, met behulp van een javascript-programma, zonder gebruik te maken van bekende bugs in de software. Hij voerde de aanval ook uit op Linux. Bos lichtte zijn onderzoek woensdag toe in het programma BNR Digitaal en presenteert het zowel op het IEEE symposium over beveiliging en privacy als op de Blackhat-conferentie. Het onderzoek werd uitgevoerd in samenwerking met Erik Bosman, Kaveh Razavi en Cristiano Giuffrida.

De aanval bestaat uit twee componenten. De eerste maakt volgens Bos gebruik van een tekortkoming in dram-geheugenchips. Deze techniek is niet nieuw en staat bekend als rowhammering. Door snel achter elkaar bepaalde geheugenrijen te activeren, kan de staat van aangrenzende geheugencellen worden veranderd. Het gevolg daarvan is dat een bitwaarde van 0 naar een waarde van 1 kan worden geflipt. Dit is mogelijk doordat de afstand tussen de verschillende cellen op geheugenchips klein is.

De tweede component van de aanval is het feit dat Windows 8.1 en 10 en bepaalde virtualisatiediensten standaard gebruikmaken van een geheugenoptimalisatietechniek, die bekendstaat als deduplicatie. Daarbij wordt identieke informatie, die op twee verschillende memory pages aanwezig is, samengevoegd op dezelfde fysieke pagina. Dit heeft het gevolg dat ruimte kan worden bespaard bij het opslaan van informatie.

De aanval gaat ervan uit dat een aanvaller weet dat er op een bepaalde plek in het geheugen een geheim aanwezig is, bijvoorbeeld in de vorm van een wachtwoord of een adres van programmacode. Bos legt uit dat een aanvaller vervolgens een grote hoeveelheid overeenkomende memory pages genereert, die alleen afwijken op het gebied waar het wachtwoord is opgeslagen.

Als een van die gegenereerde bytes overeenkomt met een van de 'geheime' bytes, dan wordt deze gededupliceerd door het systeem. Door in de gedeelde memory page te schrijven moet de deduplicatie weer ongedaan worden gemaakt, waardoor een tijdsverschil optreedt. Dit verschil is bijvoorbeeld met een javascript-programma in de browser uit te lezen. Doordat de aanvaller weet welke pagina werd aangepast, weet hij uiteindelijk ook het wachtwoord te achterhalen.

Daar komt bij dat het ook mogelijk is om via deze techniek data naar bepaalde plekken in het geheugen te schrijven, aldus Bos. Daarbij maakt hij gebruik van de eerdergenoemde tekortkoming in de dram-chips, door eerst op zoek te gaan naar geheugengebieden waar hij bits kan flippen. Daarna maakt hij op die plek een geheugenpagina aan, die overeenkomt met de pagina waar gevoelige gegevens staan. Door de overeenkomst gaat het systeem over tot deduplicatie en kan de aanvaller ervoor zorgen dat de daaruit voortkomende gegevens op de juiste plek komen te staan, waar bit flipping mogelijk is.

Door deze handeling vervolgens uit te voeren, is het op die manier mogelijk om de gevoelige informatie aan te passen, wat bijvoorbeeld kan leiden tot privilege escalation. Daarmee kan een aanvaller zichzelf hogere rechten toewijzen en zo verschillende handelingen op een systeem uitvoeren.

De ernst van deze aanval ligt in het feit dat er weinig tegen gedaan kan worden en dat er geen bestaande bugs in software voor nodig zijn, bijvoorbeeld een zero day. Volgens Bos is Microsoft al enkele maanden bezig met een oplossing, maar deze is op dit moment nog niet beschikbaar. Het uitschakelen van deduplicatie zou een mogelijkheid zijn, maar dat heeft grote gevolgen voor de opslag van gegevens, met name op apparaten die maar een kleine hoeveelheid geheugen bezitten. Bos besloot om met zijn bevindingen naar buiten te treden, om duidelijk te maken dat het vertrouwen in veel geheugenchips misplaatst is.

Reacties (71)

[MadEgg]

De omschrijving lijkt toch heel erg op een lek in software te wijzen, nameijk een lek in de manier waarop Windows met het geheugen omgaat.

Sowieso zou Javascript natuurlijk geen enkele zeggenschap moeten hebben over hoe, wat en waar in het geheugen de gegevens opgeslagen worden, veel hoger-level dan Javsascript raak je niet.

Fix lijkt me ook redelijk eenvoudig op basis van het artikel: voeg random delays in bij het inlezen en wegschrijven van data. Zolang dit in op microseconde-schaal gebeurt zal het voor de performance niets uitmaken maar heb je opeens helemaal niets meer aan die timings. Al zou je al verwachten dat door bijvoorbeeld threading / scheduling dergelijke timings niet betrouwbaar zijn.

Daarnaast is row hammering in DDR4 ook aanmerkelijk minder effectief. Ik heb zelf diverse tests gedraaid op DDR4-geheugen waarbij dagenlang row hammering geprobeerd werd, zonder enig succes.

ECC geheugen lost het natuurlijk al helemaal op. Dat zou ook wel eens de standaard mogen worden, maar Intel lijkt dit moedwillig tegen te houden door ECC niet op de mid- en toprange-processoren en chipsets te ondersteunen.

[i-chat]

dat zie ik toch anders, want hoe je het ook wendt of keert elk stuk op hardware draaiende software heeft Random Access Memory toegang nodig, dat wil zeggen dat je vanuit een OS niet of nauwelijks kunt tegen gaan dat geheuge kan worden geschreven (of iig ten dele) en weer worden gelezen ...

als je voor elke mogelijke programmeertaal ingang random delays moet gaan inbouwen om mogelijke dedub-atacs tegen te gaan dan wordt je OS niet alleen baggertraag maar ook nog eens onhuodbaar complex, al was het alleen al omdat je in computer-land eigenlijk standaard te maken hebt met pseudo-random en nooit met true-random, en omdat dit zo is, los je daar dit probleem niet mee op, want pseudo-random is voorspelbaar, en betekent dus dat er hoeguit een extra laag complexiteit aan deze hack wordt gevergd, maar geenszins een onmogelijkheid.

[Anoniem: 343906]

Wellicht is deze link naar een pagina van Morphisec interessant voor je? http://www.morphisec.com/how-it-works/

[Armin]

Fix lijkt me ook redelijk eenvoudig op basis van het artikel: voeg random delays in bij het inlezen en wegschrijven van data

Deze aanval lijkt dan ook erg op de Padding Oracle attacks op TLS. Het toevoegen van delays werkt dat ook. Al moeten ze niet random zijn, want dat begraaft het signaal enkel in ruis waardoor het enkel moeilijker wordt/langer duurt om het te vinden. Je moet ze bewust anti-patroon proberen te maken, zodat de timing verschillen verdwijnen/klein worden.

Dat echter vertraagd ook de werking van je memory management. De vraag is of dat opweegt tegen deze aanval die erg, heel erg, theoretisch is. Aanpak van populaire attack vectors (bepaalde Javascript patronen) zoals Google al eens deed met Chrome, is wellicht/waarschijnlijk voldoende.

ECC geheugen lost het natuurlijk al helemaal op. Dat zou ook wel eens de standaard mogen worden, maar Intel lijkt dit moedwillig tegen te houden door ECC niet op de mid- en toprange-processoren en chipsets te ondersteunen.

ECC zou natuurlijk helemaal niet nodig hoeven zijn. Het kunnenf lippen van een bit in een bank anders dan diegene waar je schrijft is in principe natuurlijk een hardware defect. Echter omdat het zo zeldzaam werd geacht, is er nooit rekening mee gehouden bij de timings van DDRx geheugen. Die zijn zo scherp afgesteld dat het echter dus toch mogelijk blijkt.

In feite is row hamering het misbruik van een hardware defect wat geacht werd nooit voor te komen in normaal gebruik.

[bwerg]

In feite is row hamering het misbruik van een hardware defect wat geacht werd nooit voor te komen in normaal gebruik.

Als je het hebt over nadenken over security-eisen dan is 'normaal gebruik' natuurlijk wel een domme aanname...

[Armin]

Ik denk niet dat er bij het ontwerp van DDR specifiek zo nagedacht is over security. Dat is ook geen schande. Er is een drijfveer om steeds sneller geheugen te maken. Dat is gelukt, maar het bleek later dat onder bepaalde zeer zeldzame omstandigheden je een bitfout kunt krijgen. Dat is in principe een corruptie-fout.

Voor consumentenproducten is dat geen probleem omdat bij normaal of wellicht beter gesteld typisch gebruik dat soort fouten pas optreden eens in de heel veel miljoen gebruikers.

Pas weer later kwamen er mensen op het idee dat je dit wellicht kon misbruiken.

Mijn punt was dan ook meer om aan te geven dat het hier in feite om een hardware defect gaat inherent aan het design van DDRx. ECC is dan nog steeds enkel een lapmiddel. Een ander lapmiddel is de timings van het geheugen iets trager zetten, zodat de fout (nog) minder voorkomt, zodat zelfs bij gerichte exploit-pogingen het verwaarloosbare kansen zijn.

Maar ECC verhoogt kosten en dat laatst verlaagd prestaties. Dus het is maar de vraag of dat een acceptabele oplossing is voor een probleem dat vooralsnog vooral erg theoretisch is.

[Sidle]

ECC verhoogt de kosten, tijdelijk, na verloop van tijd zal de prijs vanzelf omlaag gaan, zoals we dit met ssd's ook zien, tenminste als ECC de standaard word.

[Durandal]

ECC kost je 1 bit per byte extra dus je kan grofweg stellen dat ECC 12% meer moet kosten. Ook na verloop van tijd.

[cdwave]

ECC is geen "lapmiddel" maar een serieuze oplossing voor een veel voorkomend probleem. Bitfouten komen in alle memory elementen voor, dat kan zelfs komen door kosmische straling (op aarde doorgaans geen probleem, in de ruimte echter zijn met name FPGA's blijkbaar gevoelig hiervoor). Zelfs de CPU caches, doorgaans SRAM, zijn gevoelig voor een aantal van dit soort defecten.

Wij consumenten vinden die 12% extra kosten blijkbaar niet opwegen tegen de toegevoegde waarde, en dus kopen we massaal non-ECC RAM.

Mits goed uitgevoerd in hardware verlaagt (met een "t" graag) de toevoeging van ECC de prestaties niet.

[Armin]

ECC is geen "lapmiddel" maar een serieuze oplossing voor een veel voorkomend probleem. Bitfouten komen in alle memory elementen voor, dat kan zelfs komen door kosmische straling (op aarde doorgaans geen probleem, in de ruimte echter zijn met name FPGA's blijkbaar gevoelig hiervoor). Zelfs de CPU caches, doorgaans SRAM, zijn gevoelig voor een aantal van dit soort defecten.

Klopt, wat ik dus bedoelde dat ECC een lapmiddel is voor row-hammering. Elk geheugen heeft zoals je aangeeft inherente foutmarges. Die zijn normaal gesproken klein genoeg dat dat voor consumenten apparatuur wordt dat als acceptabel gezien.

Vandaar ECC voor bedrijven. Maar als row-hammer bescherming is het een lapmiddel, want het is een inherent defect van de DDRx spec en niet zozeer exrern (kosmische straling, spanningspieken) of nevenefefcten van CMOS-storingen, slijtage, etc.

[Cerberus_tm]

Maar ECC lijkt juist geen afdoende bescherming te bieden tegen rowhammer: het maakt het slechts wat minder effectief:
http://security.stackexch...mputer-against-row-hammer

DDR4 van de juiste fabrikanten (Samsung, en in mindere make Hynix) lijkt rowhammer inderdaad redelijk tegen te houden (zie bovenstaande link), maar van Micron niet.

Of heb jij andere resultaten? Ik ben extreem benieuwd naar wat voor test jij hebt uitgevoerd en wat precies de resultaten zijn.

Je zou zelfs een antwoord kunnen plaatsen op die site waar ik naar linkte!

[Armin]

ECC werkt in principe wel degelijk afdoende, mits je maar goed genoeg ECC doet. Dat laatste is echter het punt. ECC is een kostenpost, en dus zijn er verschillende niveaus. Veel goedkopere ECC varianten kunnen enkel bepaalde fouten herstellen. En dan beschermt ECC inderdaad niet tegen bepaalde vomen van rowhammer corruptie.

Je kunt ook de timings van je geheugen trager zetten als je echt bang bent voor dit soort aanvallen.

Uiteindelijk is het een kwestie van geheugen dat niet langer de inherente fout heeft van DDRx. Dat bestaat, maar is vooralsnog optioneel (want een extra kostenpost).

[Cerberus_tm]

Heb je hier een bron voor? Je hebt het dan over ECC-geheugen dat veel meer dan b.v. 2 bitflips tegelijk kan herstellen? Bestaat dat?

Ik ben al een tijd op zoek naar informatie, over welk soort RAM ik moet kopen voor mijn nieuw te bouwen computer (ca. €600) om immuun te zijn voor rowhammer.

De bronnen die ik heb gevonden zeggen dat ECC-geheugen niet afdoende is. Of in elk geval geen ECC-geheugen dat ik zelf gewoon kan kopen. Maar heel veel recente, betrouwbare bronnen heb ik niet kunnen vinden.

[Armin]

De term ECC is dan ook een beetje ene losse term. Vroeger maakte men nog wel eens explciet verschil tussen geheugen met een parity bit en ECC geheugen wat ook echt correctie kan uitvoeren.

Omdat de meeste fouten single-bit zijn heb je gelijk dat de meeste ECC varianten enkel 2-bit zijn. Immers 1-bit kan detecteren en met 2-bit ECC kun je een 1-bit fout corrigeren.

Maar multi-bit ECC geheugen bestaat gewoon. O.a. diverse HP servers hebben support. Als jij zegt dat dat zeldzaam is, geloof ik je graag, maar dat is dan nieuw voor mij.

[Cerberus_tm]

Okee, het ging mij erom dat de uitspraak "ECC beschermt tegen rowhammer", die overal op het Internet te vinden is, in de praktijk voor het meeste ECC-geheugen dat zo her en der tegenkomt niet klopt.

Ik ken dat 3+-bit(?)-ECC-geheugen dat jij noemt niet, maar zou het wel overwegen als dat betaalbaar is voor een beetje een normale thuis/spel-computer. Enig idee? Of waar ik op zou moeten zoeken? Ik wil namelijk binnenkort een nieuwe computer bouwen met redelijk bescheiden budget.

[Seal64]

Ik zou niet graag zien dat het microseconden gaat duren om je geheugen te kunnen lezen. De access times van DDR4 geheugen liggen namelijk nog een factor 1000 lager - die meet je in nanoseconden.

[MadEgg]

Zeker. Niet op OS-niveau. Maar wel in Javascript. Dat een dergelijke attack werkt is bekend. Wat ik vooral ernstig vind is dat dit blijkbaar de exploiteren is via Javascript. De performance van Javascript is sowieso al bagger dus die paar microsecondes maken dan echt niet zo veel meer uit.

Juist het feit dat het in de browser gedraaid worden bij het bezoeken van een pagina maakt het goed toepasbaar. Als je programma's moet downloaden wordt het al een stuk lastiger, en voer voor virusscanner-bouwers. Row hammering levert wel bepaalde access patronen op die toch redelijk makkelijk te herkennen zouden moeten zijn door een virusscanner, of het OS.

[koelpasta]

Niet op OS-niveau. Maar wel in Javascript.

Hangt er helemaal vanaf.
Als je in een javascript loop het geheugen int voor int gaat uitlezen dan is dat turbotraag ja.
Maar met slimme truuks kun je met weinig code de interpreter flink aan het werk zetten en vinden er geheugentransacties plaats op gecompileerde snelheid, niet op geinterpreteerde snelheid.

[koelpasta]

Row hammering levert wel bepaalde access patronen op die toch redelijk makkelijk te herkennen zouden moeten zijn door een virusscanner, of het OS.

Maar heb je enig idee wat voor impact dat heeft op de performance? Elke geheugentransactie eerst nog met een stuk code checken... gaat um niet worden denk ik.

[CEx]

Niet alleen Windows.

Je fix lost niets op, het maakt het alleen complexer om de aanval uit te voeren. ECC ram werd te lang te duur gevonden, wellicht dat dit helpt om het weer onder de aandacht te krijgen.

[koelpasta]

voeg random delays in bij het inlezen en wegschrijven van data.

Dus in een tijd waarin we steeds sneller ram nodig hebben stel jij voor om een globale latency in te bouwen? Lekker handig
En als je toch die kant op wilt, neem dan gewoon trager ram dat dit probleem niet heeft.

Zolang dit in op microseconde-schaal gebeurt zal het voor de performance niets uitmaken

Dan moet jij maar eens kijken hoeveel geheugentransfers er in een microseconde plaatsvinden. En allemaal krijgen ze die latency er bovenop. Lijkt me niet bevorderlijk voor performance.

Ik denk inderdaad dat je de fysieke eigenschappen van het ram rowhammer-proof moet maken.
Alle andere methodes lijken het voordeel van snelle toegang tot ram teniet te doen. Een memory access wordt dan (gemiddeld) nooit sneller dan die latency.

[SED]

Zie artikel

Hij voerde de aanval ook uit op Linux

[jostefa]

Dit is precies de reden waarom ik al jaren opteer voor ecc memory. Schroeder schreef daar in 2009 al over zie: https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

edit: typo

[Reactie gewijzigd door jostefa op 22 juli 2024 22:51]

[Cerberus_tm]

Behalve dat ECC vaak niet schijnt te beschermen tegen rowhammer (sorry, ik spam deze link hier even, want iedereen lijkt ervan uit te gaan dat ECC hiertegen beschermt):
http://security.stackexch...mputer-against-row-hammer

[Dilkooo]

Bedankt voor de link!

[locke960]

De eerste maakt volgens Bos gebruik van een tekortkoming in dram-geheugenchips. Deze techniek is niet nieuw en staat bekend als rowhammering. Door snel achter elkaar bepaalde geheugenrijen te activeren, kan de staat van aangrenzende geheugencellen worden veranderd.

Noem me ouderwets, maar vroeger hadden we een naam voor dergelijk geheugen: defect.

[bwerg]

Dan is het nog steeds nieuws: de meeste consumentenhardware is defect en daarmee een beveiligingslek.

Ik zie al mensen noemen dat verschillende merken kwetsbaarder zijn dan anderen, ik ben nu wel benieuwd naar waar op te letten bij geheugen-aanschaf.

[Reactie gewijzigd door bwerg op 22 juli 2024 22:51]

[Ventieldopje]

De hoogleraar systeem- en netwerkbeveiliging demonstreerde de techniek op een Windows 10-machine met de nieuwste versie van de Edge-browser, met behulp van een javascript-programma, zonder gebruik te maken van bekende kwetsbaarheden in de software. Hij voerde de aanval ook uit op Linux.

Volgens Bos is Microsoft al enkele maanden bezig met een oplossing, maar deze is op dit moment nog niet beschikbaar.

Ehh, en op linux is het ook gelukt of dat niet? Lijkt mij stug aangezien er vaak ASLR wordt toegepast en het lastig voor deze aanval om succesvol te zijn. Dat terwijl deduplicatie de aanval juist in de hand speelt. Lijkt mij dus meer een Microsoft probleem dan wat anders...

[Whatson]

http://www.cs.vu.nl/~kaveh/pubs/pdf/dedup-sp16.pdf

On Linux, memory deduplication is known as kernel samepage merging (KSM). The implementation operates differently compared to Windows, combining both scanning and merg- ing operations in periodic and incremental passes over physical memory [7].

The authors of Rowhammer.js [17], an implementation of the Rowhammer attack in JavaScript, rely on Linux’ anony- mous huge page support. A huge page in a default Linux installation is allocated using 2MB of contiguous physi- cal memory—which spans across multiple DRAM rows. Hence, huge pages make it possible to perform double-sided Rowhammer from JavaScript

The Rowhammer bug was first publicly disclosed by Kim et al. [23] in June 2014. While the authors originally speculated on the security aspects of Rowhammer, it was not clear whether it was possible to fully exploit Rowhammer until later. Only in March 2015, Seaborn and Dullien [33] published a working Linux kernel privilege escalation ex- ploit using Rowhammer. Their native exploit relies on the ability to spray physical memory with page-table entries, so that a single bit flip can probabilistically grant an attacker- controlled process access to memory storing its own page- table information. Once the process can manipulate its own page tables, the attacker gains arbitrary read and write capabilities over the entire physical memory of the machine. In July 2015, Gruss et al. [17] demonstrated the ability to flip bits inside the browser using Rowhammer.

In this paper, we showed that our memory deduplication primitives can provide us with derandomized pointers to code and heap. We used these pointers to craft the first reliable remote Rowhammer exploit in JavaScript.

Was al mogelijk op linux ze hebben nu aangetoond dat het ook op Windows werkt

[Reactie gewijzigd door Whatson op 22 juli 2024 22:51]

[Ventieldopje]

Dat werkt dus alleen op machines die KSM aan hebben. Die doen in de meeste gevallen aan virtualisatie. Zeker niet je average joe desktop

KSM staat standaard uit vzviw aangezien het ook een negatieve impact kan hebben. Zonder KSM ben je dus niet kwetsbaar lijkt mij.

[SED]

A huge pagein a default Linux installationn is allocated using 2MB of contiguous physi- cal memory—which spans across multiple DRAM rows. Hence, huge pages make it possible to perform double-sided Rowhammer from JavaScript

Dit geeft juist aan dat het default in linux zo misbruikt kan worden.

[Armin]

Lijkt mij stug aangezien er vaak ASLR wordt toegepast

ASLR was al eerder op Windows dan Linux, maar ik betwijfel of dat helpt. Immers dat gaat over virtuele addressen. Het is iet uit te sluiten dat ondanks virtuele randomness, het nog steeds fysiek niet random is. Dat hangt immers van de memory management functies en hardware af.

En in dit geval wordt gebruik gemaakt van de eigenshap dat verschillende address spaces op dezelfde fysieke plaats opgeslagen wordt.

Ik denk dus niet dat ASLR hier bescherming biedt. ASLR s daar immers ook niet voor bedoeld.

[Stoney3K]

Ehh, en op linux is het ook gelukt of dat niet? Lijkt mij stug aangezien er vaak ASLR wordt toegepast en het lastig voor deze aanval om succesvol te zijn. Dat terwijl deduplicatie de aanval juist in de hand speelt. Lijkt mij dus meer een Microsoft probleem dan wat anders...

Dat dacht ik dus ook. In feite is de deduplication die Microsoft toepast dus de zwakke plek waar hij misbruik van maakt, alleen kost het wat meer tijd dan een "simpele" 0-day exploit.

[LoCuTuS2000]

Na het lezen van dit verhaal vraag ik mij af of wat er nodig is om dit op een systeem uit te voeren. Kan dit alleen als je ongestoord toegang hebt tot het OS of kan dit ook volledig ongemerkt op afstand?

[supersnathan94]

Een random website kan dit doen mits je lang genoeg op de pagina bent. Alle client side code zoals Javascript kan dit uitvoeren zover ik het artikel begrijp.

[Armin]

Mits je weet waar de 'belangrijke' informatie opgeslagen is. En dat weet je als aanvaller doorgaans niet omdat OS'en informatie effectief random in het geheugen plaatsen.

En dan nog is het doorgaans beperkt tot bepaalde aanvallen, zoals een elevation of privilige.

Ofwel een zeer knap staaltje werk, maar niet iets waar de doorsnee PC gebruiker nu meteen bang voor hoeft te worden.

[FreqAmsterdam]

Echt random bestaat niet. En dus is het in theorie voorspelbaar. Iemand heeft het eerder al gezegd.

[Armin]

Ik zei daarom ook "effectief random"

In de praktijk is het waarschijnlijk niet voorspelbaar, en dus "random genoeg".

[bwerg]

Echt random bestaat wel. De meeste RNGs maken daar alleen geen gebruik van.

[SwiftPengu]

Dat zijn dan PRNGs.

[TheBrones]

Werkt dit ook met ECC geheugen?

[Kalief]

Bitflipping zou door ECC moeten worden opgemerkt en gecorrigeerd.

[Cerberus_tm]

Maar alleen als er slechts 1 of 2 bits geflipt worden, als ik het goed begrijp, en rowhammer kan er meer flippen, althans op bepaalde soorten geheugen. (Of misschien wel op alle soorten alleen is dat nog niet bekend.) Dus ECC houdt rowhammer niet tegen, voor zover ik weet; het maakt het alleen wat moeilijker uit te voeren.
http://security.stackexch...mputer-against-row-hammer

[Reactie gewijzigd door Cerberus_tm op 22 juli 2024 22:51]

[Anoniem: 20901]

Wou net zeggen ja, waarom kan je ongemerkt een bit flippen?

[JustMitchie]

Dus kort gezegd:
Het al bekende bit-flipping kan nu op een nieuwe manier worden aangeboord door een browser based item?

[Anoniem: 167912]

Ik snap het niet helemaal: men moet weten op welke plaats in het geheugen iets opgeslagen ligt, maar dat kan men toch onmogelijk achterhalen?

[koelpasta]

Soms zijn die plekken redelijk voorspelbaar.

[680x0]

Ik begrijp technisch gezien volledig wat hij doet en het klopt dat dit extreem theoretisch mogelijkheden kan geven.

Maar ik wil de eerste tool nog zien die er effectief, en in een aannemelijke tijdspanne, informatie mee kan 'minen', want daar komt het op neer.. Informatie proberen opgraven door theoretische trukjes toe te passen...

[bdbfz]

De deduplicatie techniek wordt niet erg correct beschreven in dit artikel (niet bytes worden gededuplicate, maar pages (4K)), maar de techniek is al een tijdje bekend. VMware heeft al eind 2014 beslist om inter-VM deduplicatie standaard uit te zetten in nieuwe update releases van vSphere 5 (en in vSphere 6 van bij de originele releases).

VMware ziet het risico tegelijk als "onrealistisch" op real-world systemen: als er bijvoorbeeld veel VMs tesamen draaien, kan je niet weten met welke VM jouw pages gededuplicate worden. En als er meerdere sockets/numa nodes zijn, heb je slechts een 1/n kans dat jouw VM in dezelfde node draait als de target VM, en er werd sowieso niet gededuplicate tussen nodes. Ook gebruiken veel enterprise applicaties large pages (2MB ipv 4KB) en daar levert deduplication niets op, de kansen om identieke pages te vinden zijn te klein. En voor deze attack is het ondoenbaar om voldoende guesses in je eigen geheugen te stoppen om daarna de juiste guess te vinden door de timing van writes te vergelijken.

https://kb.vmware.com/sel...playKC&externalId=2080735