Onderzoekers maken misbruik van fysieke tekortkomingen ddr3-geheugen

Onderzoekers van Google zijn erin geslaagd om op een x64-systeem met ddr3-geheugen bits in het geheugen te manipuleren door gebruik te maken van tekortkomingen in het fysieke geheugen. Door bepaalde plekken in het geheugen telkens te benaderen, kunnen aangrenzende bits worden 'geflipt'.

Door de aanval zou een proces met normale gebruikersrechten schrijftoegang kunnen krijgen tot andere, beveiligde delen van het geheugen. Dat schrijven de onderzoekers van Googles Project Zero. Daarmee zouden aanvallers met normale gebruikersrechten bijvoorbeeld root-toegang kunnen krijgen, een sandbox kunnen omzeilen of zelfs uit een virtuele machine kunnen breken.

Het probleem dat de Google-onderzoekers misbruiken bevindt zich niet in de software, maar in het fysieke 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 de Google-onderzoekers maakten twee proof-of-concepts om aan te tonen hoe dit concreet kan worden misbruikt. Aanvallers moeten daarvoor tienduizenden keren in minder dan een seconde geheugen benaderen, waardoor aangrenzende bits kunnen flippen.

De ram-hackers, die hun hack Rowhammer hebben genoemd, deden hun onderzoek op een x64-Linux-systeem, maar in principe is de hack niet aan een bepaalde instructieset of besturingssysteem gebonden. De onderzoekers leunden wel op een specifieke instructie uit de x86-instructieset, clflush, om de cache te omzeilen en tienduizenden keren rechtstreeks toegang te krijgen tot het geheugen, maar vergelijkbare instructies in andere instructiesets zouden daarvoor ook bruikbaar zijn.

De kwetsbaarheid is in verschillende ddr3-geheugenreepjes aanwezig, al geven de Google-onderzoekers niet aan welke modellen en fabrikanten kwetsbaar zijn. Duidelijk is wel dat ddr4-geheugen niet kwetsbaar is, evenals geheugen met error correcting code. De onderzoekers hebben een tool gemaakt waarmee gebruikers kunnen testen of hun pc is getroffen, al waarschuwen de onderzoekers dat de test niet waterdicht is: als de tool aangeeft dat een pc niet is getroffen, wil dat niet zeggen dat de aanval niet op een andere manier kan worden opgezet. Ze hebben zelf een aantal laptops getest, waarvan een deel kwetsbaar was. De onderzoekers vonden nog geen kwetsbare desktops.

De onderzoekers maakten twee proof-of-concepts. In het eerste geval ging het om een tool in Native Client, een deel van Chrome dat websites gecompileerde code in een webbrowser laat draaien. De exploit wist uit de sandbox van Native Client te 'breken', waardoor het rechtstreeks kon communiceren met het geheugen van het besturingssysteem. Deze exploit is inmiddels onschadelijk gemaakt, al is onduidelijk of de patch al de stabiele versie van Chrome heeft bereikt.

Daarnaast maakten de onderzoekers een exploit die als een normaal x64-proces draait, maar hogere gebruikersrechten weet te krijgen en zo toegang krijgt tot het volledige geheugen. Volgens de onderzoekers is dit probleem moeilijker op te lossen met bestaande hardware. Het vervangen van kwetsbare ddr3-reepjes door niet-getroffen geheugen biedt wel soelaas.

Reacties (55)

Ik snap sowieso niet waarom niet al het geheugen ECC heeft. De cache van de CPU heeft ECC, een SSD en een CD heeft ECC. ARM computers hebben vaak (altijd?) ECC overal volgens mij. Ik zie het graag gebeuren, als iedereen overstapt dat is het kostenverschil verwaarloosbaar.

Ik weet nog goed dat Microsoft in de jaren 90 of rond 2000 ergens ECC verplicht wou stellen voor de nieuwste WIndows release. Destijds zijn ze weggehoond omdat hun software zelf nog zo onstabiel was. Jaren later hebben ze het nog eens geprobeerd, met het argument dat hoewel er steeds minder fouten zijn per geheugencel, er zoveel meer geheugencellen bij komen dat kans op een fout gelijk blijft of groter wordt.
nieuws: Microsoft pleit voor ecc-geheugen in clients

[Reactie gewijzigd door Gaming247 op 10 maart 2015 09:44]

Integendeel, er is veel te zeggen om júist geen ECC toe te passen. ECC is een error correcting mechanisme, oftewel iets dat naderhand, als het leed al geschied is, een poging waagt om data te reconstrueren. Zoals het gezegde gaat: voorkomen is beter dan genezen - en zo werkt dit ook in engineering. Zodra je moet genezen, heb je iets heftig fout gedaan in het ontwerp van je systeem.

DDR, net als alle andere subsystemen in je computer, is erop ontworpen om binnen zodanige toleranties te blijven dat de kans op fouten acceptabel klein is. Dit is niet een afterthought; het is van het begin af aan ontworpen op een specifieke bit error rate. By design is het dus foutvrij voor iedere praktische toepassing.

ECC schaalt extreem slecht. Je moet ca 15% extra diespace investeren om op zijn best een factor 30 betere error rates te halen. Ter vergelijking: simpelweg je die size 15% vergroten betekent een factor TIEN lagere error rates (omdat grotere geometrieën bij dezelfde procestechnologie nauwkeuriger zijn).

En hier zit nog een belangrijke issue: zolang je software niet robuust kan omgaan met ECC, heb je er niet heel veel aan. ECC werkt maar tot op zekere hoogte, en als je echt hoge capaciteiten en hoge bandbreedtes gaat pushen krijg je een macroscopische hoeveelheid onherstelbare fouten. Je computer crasht doorgaans alsnog volledig bij een onherstelbare error.

En dan nog het belangrijkste: de kans op fouten in je geheugen is véééél kleiner dan de kans op fouten in je opslagmedium of software. Het heeft dus veel meer zin om te investeren in betere (robuustere) storage en softwareontwikkeling dan in ECC-geheugen.

[Reactie gewijzigd door mux op 10 maart 2015 16:51]

Ik zou graag een onderbouwing zien van al je stellingen en cijfers ... want het rammelt wel heel erg.

Waar wil je cijfers over? Welk aspect is niet duidelijk?

Waar niet .. Ik zie nergens een onderbouwing over de (juiste werking) van ECC, waarom iets "By design" "foutvrij" is etc.etc Ja binnen de spec voldoet het geheugen (er is kans dat er iets omvalt) - maar het gaat juist om de gevolgen van het omvallen - niet of iets aan de spec voldoet.
Ik lees een 15% grotere Die .. waarom? Bron? En dat dit slecht een factor 3 aan betere error rates zou opleveren .. ook hier weer .. een berekening of een bron?

(ugh, heb ik een reactie geschreven, wiste hij zichzelf )

Goed, wat harde cijfers erbij: Mijn aanklacht tegen ECC is dat je heel veel extra betaalt voor maar een heel klein beetje beter geheugen. ECC werkt, natuurlijk, maar het werkt maar weinig.

DRAM ECC werkt bijna universeel met [72,64] hamming-code, oftewel 8 bits parity bovenop iedere 64 bits data. Deze hamming-code is theoretisch exact 32:1 efficiënt, oftewel voor iedere 33 fouten in het geheugen kunnen er 32 worden hersteld. De praktijk komt vrij goed hiermee overeen (google-studie: 8.2% correctable, 0.28% uncorrectable error rate).

Echter, JEDEC specificeert voor ieder soort geheugen een toelaatbare error rate. De toelaatbare error rate van DDR3 is 1e-12, en dit is inherent aan het ontwerp. Voor DDR4 is de error rate vastgesteld op 1e-16, een factor tienduizend beter. Hoe doen ze dat? Simpel: strengere eisen stellen aan het ontwerp, specifiek de signaallijnen. De specs zijn helaas niet vrij te bekijken, maar o.a. deze blogpost spreekt erover: http://blog.asset-interte...ry-voltage-margining.html

DDR4 is niet groter of duurder. Dit staat nog helemaal los van mijn opmerking over feature size vs. error rate (http://www.research.ibm.com/acas/projects/01prem.pdf). Puur en alleen door hoe het DRAM ontworpen is, met een lage error rate als één van de belangrijkste ontwerpdoelen, kan een aantal orde-grootten worden gewonnen in error rate. ECC doet verhoudingsgewijs geen moer, terwijl het op zijn allerminst 12,5% duurder is. Nogmaals: ECC schaalt slecht.

Maar belangrijker nog: stel ik wil een server in elkaar zetten: ééntje met ECC, ééntje zonder. Moederbord zonder ECC-ondersteuning: sub-50 euro. Moederbord met ECC-ondersteuning: goedkoopste dat ik kan vinden is €175. CPUs die ECC expliciet ondersteunen zijn ook véél meer dan 12,5% duurder. Je betaalt een gigantische hoeveelheid geld voor een, in computertermen, minimale upgrade.

En dit alles terwijl error en crash rates door softwarefouten domineren in veruit het grootste deel van de markt.

Er is eigenlijk maar één markt waar ECC echt zin heeft, en dat is in high-performance computing. Als je een hele simulatie op een supercomputer kunt weggooien als ergens een fout in is gekropen. Dan is het fijn om een 32x kleinere kans op fouten te hebben. Of, als je echt robuust bent, nog beter met nieuwere ECC-methoden zoals Chipkill (maar die hebben 2x zoveel parity nodig en kosten aardig wat cpu-power).

En mocht je goedkoop ECC willen; veel "gewone" AMD CPU's ondersteunen gewoon ECC, itt bij Intel alleen dure modellen.
Die prik je op n willekeurig mobo, en dan kan je vanuit Linux de ECC op de northbridge aanzetten (met ecc_enable_override).
Ikzelf gebruik dat ook (Athlon II X2) om het te kunnen weten als er een fout (zoals deze rowhammer, of een lage kwaliteit dimm) is. Heb je geen ECC, dan merk je bitflips niet op tenzij die leiden tot een crash oid.
Overigens, vooral bij "zelf-helende" filesystems als ZFS en btrfs is ECC RAM aan te raden, omdat bitflips in RAM daarbij voor fs corruptie kunnen zorgen.
In elk geval blij met mn goedkope ECC oplossing voor dat veilige gevoel, always.

Enige probleem hiermee weer is dat het soms verrekte moeilijk is om uit te vinden welk moederbord dit daadwerkelijk ondersteunt. Je moet vaak putten uit een hele beperkte lijst van 'known compatible' moederborden (of bijv. navraag doen in het DIY RAID NAS topic e.d.) om er zeker van te zijn dat het ook daadwerkelijk werkt. En dan heb je weer geen profijt van specifieke features of de nieuwste snufjes.

Ik bedoel, het is een beetje doelloos om vandaag de dag nog een ECC moederbord met DDR2 te gebruiken, gezien DDR2 van zichzelf een ca. 10 keer hogere error rate heeft dan DDR3 (hangt sterk af van de modules, maar toch). Dan win je niks op bijv. een véél zuinigere Kabini zonder ECC.

Jawel, daar win je op dat je kan weten wanneer er bitflips plaatsvinden, iets wat je gewoon niet KAN weten zonder ECC (tenzij je het softwarematig implementeert ofzo). Want het corrigeert niet alleen, het informeert je ook over (herstelde en onherstelbare) fouten.
Dus, dan weet je dat er een probleem is, je mss een DIMM moet vervangen, met je ruimteschip wat verder van de zon af moet vliegen, of meer lood in je atoombunker moet stoppen. Het is echt niet alleen symptoombestrijding maar helpt ook bij diagnose.

En ja, als uit allerlei statistieken blijkt dat de kans enorm klein is op bitflips (terwijl dit artikel JUIST gaat over hoe bitflips te veroorzaken en exploiten, al je statistieken ten spijt!), kan je besluiten dat je het erop waagt en geen ECC hoeft (zoals jij). Een ander heeft liever wat meer zekerheid en wil ECC (zoals ik).

En ja inderdaad, meestal als iets crasht, is het een softwarebug o.i.d.. Dat is inderdaad een ander probleem dan waar ECC tegen beschermt, dus dat is ook helemaal niet relevant in de discussie over het nut van ECC.

Voor mij persoonlijk iig is een Athlon II X2 met MSI 785GM-E51 en 8GB ECC, een prima oplossing gebleken voor die extra zekerheid, en ik heb er niks voor hoeven inleveren, alleen een paar tientjes extra voor de DIMMs.
Ja, dat zou je van tevoren uit kunnen zoeken voordat je zoiets koopt, nou daar zijn we tweaker voor nietwaar

ECC heeft nog een voordeel. En dat is dat je het tenminste weet als er geheugenproblemen zijn. Dan kun je iets aan doen.
Zonder ECC, of op zijn minst een parity bit, weet je van niks en gaat de datacorruptie stilletjes door.

Aantoonbare betrouwbaarheid is vaak belangrijker dan een hoge theoretische betrouwbaarheid.

Uit 1989 vind ik een artikel over gebruik van Hamming (7,4) code voor ECC. Deze code kan 2 fouten vinden (per 7 bit) en 1 verbeteren. De summary voor het artikel meldt 20% extra benodigde ruimte, maar het hele artikel heb ik helaas geen toegang toe.

Furutani, K.; Arimoto, K.; Miyamoto, H.; Kobayashi, T.; Yasuda, K.; Mashiko, K., "A built-in Hamming code ECC circuit for DRAMs," Solid-State Circuits, IEEE Journal of , vol.24, no.1, pp.50,56, Feb. 1989
doi: 10.1109/4.16301
URL: http://ieeexplore.ieee.or...number=16301&isnumber=584

[Reactie gewijzigd door kidde op 10 maart 2015 16:31]

Ik heb wel toegang tot dit artikel (maar dat beantwoord nog niet de vragen).

Misschien als achtergrond is dit documentje aardig: http://h20000.www2.hp.com...l/c00256987/c00256987.pdf
Maar er is vast wel meer leuks te vinden.

Verder voegt ECC daarnaast niet alleen correctie toe, maar ook detectie. Eigenlijk is dat mss nog wel belangrijker, weten dat er iets fout gaat.
Wat betreft "Die area" heb je extra bits nodig tbv de ECC - bv 72 bit ipv 64 bit (+12.5%). De ECC detectie/correctie wil je niet lokaal (RAM) doen maar eigenlijk pas op het moment dat je de data nodig hebt. Ook op een databus kan wat mis gaan etc.

Ja, veruit de meeste errors komen niet door daadwerkelijke fouten in het DRAM, maar door brakke (relatief) signaalintegriteit tussen het DRAM en de processor/NB. Dat is één van de belangrijkste conclusies uit een onderzoek 'DRAM errors in the field' (2012), waar men een factor 1000 verschil tussen DRAM-fouten zag tussen een paar verschillende nodes. Wat bleek? Een fout in het BIOS zorgde ervoor dat (deels) het verkeerde SPD-profiel werd uitgevoerd, waardoor een latje RAM de verkeerde timings gebruikte en precies op de grens van voldoende signaalintegriteit zat.

Dus daarom wordt ECC altijd pas op het laatst mogelijke moment uitgevoerd. Da's superbelangrijk.

Beetje off topic.

ECC-geheugen heeft naar mijn mening wel een toegevoegde waarde. Het eerste om te lezen dat er op deze manier je pc gehack kan worden. Ten tweede investeren in betere storage haalt niet weg als je bestanden van je opslagmedia wil halen het altijd door je geheugen gaat dus nog steeds de kans hebt op bitrot. Een hardware matige raid haalt dit probleem ook niet weg. De vraag moet jezelf stellen wil ik de extra kosten hebben (wat voor ECC wel mee valt naar mijn mening) en je geen performance verlies wilt hebben (van voor sommige gamers kan uitmaken) of dat je data belangrijker is. ZFS is naar mijn mening het beste om bitrot tegen te gaan alleen het wordt wel aanbevolen om hier ECC voor te gebruiken anders heeft ZFS ook niet veel nut. Nu moet ik zeggen dat ik ZFS het beste filesysteem vind alleen daar verschillende meningen over. Wil je weten waarom hier is een link https://pthree.org/2012/1...rt-vi-scrub-and-resilver/. Hij verwijst ook als ik het goed heb naar andere websites met nog gedetailleerd technische informatie over ZFS en http://arstechnica.com/in...ide-next-gen-filesystems/ voor degene die geïnteresseerd zijn.

Ooit gehoord van Bitsquatting?
http://dinaburg.org/bitsquatting.html
DNS gaat de boot in door biterrors. Zo kun je, mits je de juiste domeinen in handen hebt, duizenden machines volproppen met malware (denk aan een windows update url te squatten oid).

Dit is al jaren bekend en is alleen op te lossen door.... Juist! ECC geheugen te gebruiken.

Zolang de nood niet hoog genoeg is zullen miljarden apparaten geen ECC geheugen aan boord hebben, simpelweg ivm de extra kosten en performance die je inlevert.

ECC is trager ( er moet immers gecontroleerd worden op fouten), vereist een extra chip, en kost je op z'n minst 1/9 van je geheugen. Nu is dat een minder groot probleem dan 10 jaar terug, toen wilde iedereen vooral meer meer meer. En zeg nou zelf, in de meeste gevallen is een omgevallen bitje geen probleem, als ie al omvalt. Voor bedrijfskritische systemen en servers, tuurlijk, maar daar is ECC al een stuk normaler.

En zeg nou zelf, in de meeste gevallen is een omgevallen bitje geen probleem, als ie al omvalt

Wait, what . Een omgevallen bit kan desastreus zijn. We hebben het niet over analoge data ofzo. Een bit verschil en de boel kan compleet anders worden geïnterpreteerd. In een programma kan dat leiden naar een verkeerde instructie of een verwijzing naar een volledig ander geheugenadres. In binaire bestandsformaten kan daardoor het bestand mogelijk niet meer worden ingelezen.

Kan, ja. En nu ga je even je hele geheugen nakijken en check je alle bits die erin zitten. Daarvan is heel veel gewoon leeg, dus wat daar omvalt maakt me niet uit, dat wordt rechtgezet als ik er iets naartoe schrijf. Een deel van de rest is data die je nooit meer gebruikt, waarden die wel bijgehouden moeten worden maar in de code bloat vallen, write once, read never. Weer een ander stuk zijn bitjes die alsnog gecorrigeerd worden, omdat het programma zelf al iets kan checken.

Als je kijkt hoeveel geheugenwaarden er echt kritiek zijn, denk ik dat je misschien 1 MB aan bitjes heel moet houden, de rest is niet interessant. Hoe groot is de kans op spontane bit-rot? Een Google-onderzoekje zet de score op 3500 foutjes per bank (4 GB tegenwoordig?) per jaar. Dat is bij constant gebruik, en vermoedelijk bij een vol bankje. Als je dat dan terugbrengt naar de kritieke bitjes, krijg je een paar errors per jaar.
Ga ik daar wakker van liggen? Nee. Als mijn computer 4x per jaar crasht vind ik dat best acceptabel. Is dat acceptabel voor servers? Nee. Die gebruiken dus ECC. Easy.

[Reactie gewijzigd door FreezeXJ op 10 maart 2015 11:27]

Daarvan is heel veel gewoon leeg, dus wat daar omvalt maakt me niet uit, dat wordt rechtgezet als ik er iets naartoe schrijf

Dat is dus gewoonweg onwaar. Het overgrote deel van ongealloceerde pages wordt door het OS gebruikt als file cache. Lees jij uit een file die in die cache staat, dan komt dat dus uit dat geheugen.

Een deel van de rest is data die je nooit meer gebruikt, waarden die wel bijgehouden moeten worden maar in de code bloat vallen, write once, read never.

Een deel ja. Knappe jongen als jij daar statistieken over hebt.

Weer een ander stuk zijn bitjes die alsnog gecorrigeerd worden, omdat het programma zelf al iets kan checken.

En jij denkt dat elk programma continu bezig is zijn eigen consistentie te checken? Niemand doet dat. Validatie gebeurt op input, als het eenmaal in het geheugen staat dan wordt er blind vanuit gegaan dat dat klopt. En terecht, bitjes zouden niet om moeten vallen.

Als je kijkt hoeveel geheugenwaarden er echt kritiek zijn, denk ik dat je misschien 1 MB aan bitjes heel moet houden, de rest is niet interessant

Even los van dit compleet uit te lucht gegrepen getal waar jij hoogstwaarschijnlijk geen enkel vorm van bewijs tegenover kan plaatsen, 1MB per wat? Een gemiddelde executable bevat al meer code dan dat.

Volgens mij staat er in het rapport dit:
A two-and-a-half year study of DRAM on 10s of thousands Google servers found DIMM error rates are hundreds to thousands of times higher than thought — a mean of 3,751 correctable errors per DIMM per year..

Yup, en dan is de vraag of dat drieduizend of drie-punt-nogiets is, gezien de notatie niet helemaal helder is.
Het rapport zelf zegt "8.2% of all DIMMs are affected by correctable errors and an average DIMM experiences nearly 4000 correctable errors per year."
Dat is duidelijk, en betekent voor mij dat als een bankje rot is, hij ook door en door rot is, en je dus non-stop fouten blijft krijgen. Kortom: doe een memtest, en verwijder het brakke bankje.
(ik heb mijn reactie van 10:40 aangepast, zodat de getallen weer enigszins kloppen).

[Reactie gewijzigd door FreezeXJ op 10 maart 2015 11:28]

Waar wij 3.751,00 gebruiken is dat in America andersom. Gezien de nationaliteit van de onderzoekers kunnen we er veilig vanuit gaan dat het dus om 3751 gaat.

Dat is zo'n cijfer als "er zitten twee miljoen bacteriën op de deurklink van een kantoortoilet". Je wordt er onredelijk ongerust door.

[Reactie gewijzigd door Enai op 10 maart 2015 11:45]

Geheugen is niet vaak leeg...
Geheugen wordt naartoe geschreven en dan een link weggehaald naar het adres.. Dus de data staat er dan nog wel degelijk pas als het OS in geheugen nood komt gaat hij deze data overschrijven met nieuwe data.

Maar het os heeft ook cache die het later gebruikt..

Je kan toch aardig wat data verminken, of cache dus veranderen als je hier bij komt en het os leest het later uit. Waardoor je hogere privileges krijgt of wat dan ook.

"Geheugen wordt naartoe geschreven en dan een link weggehaald naar het adres." Dat is 'leeg' voor mij, de data kan niet meer benaderd worden, en je page table geeft aan dat die cellen beschreven mogen worden. De info die er op dat punt in staat is niet meer van toepassing, en zal overschreven worden (tenzij je hele rare dingen gaat doen).

Ja het OS cachet veel data, maar hoeveel daarvan wordt daadwerkelijk gebruikt? (en ik hoop nog altijd dat die data niet teruggeschreven wordt naar de HDD bij het afsluiten...)

Veel, anders zou het OS het niet cachen. Toch?

Tuurlijk is de hit-rate van die cache relatief laag, maar dat is de kans om de lotto te winnen ook. En toch wint er quasi elke week iemand.

Het kan echter ook volledig onschuldig zijn, zoals bijv. gedurende 1/60'e seconde één verkleurde pixel op je scherm.

Interessante review om te lezen; Debunking a Myth: DDR3 RAM vs. ECC Memory Performance

En zeg nou zelf, in de meeste gevallen is een omgevallen bitje geen probleem, als ie al omvalt.

Volgens Microsoft staan geheugenfouten in de top 10 van redenen dat computers crashen. Mijn inziens moet je toch blijven werken aan een steeds stabieler en veiliger systeem, daar is dit een oplossing voor.

Tja, misschien dat geheugenfouten bij Windows voor ernstige problemen zorgen, maar ik geloof er niks van. Ik heb tonnen crashes gehad, en kan er tot nu toe 0 toewijzen aan brak geheugen. Buffer Overflows, exploits en andere rotzooi is een stuk gevaarlijker.

(een en ander neemt aan dat je je geheugen wel eens test, en je niet doorwerkt met bankjes die Memtest niet overleven)

ps. Zie die review, waar testen ze op? DDR3-1600, het ongeveer absolute minimum dat je kunt krijgen. Probeer eens DDR3-2400 ECC te vinden ofzo, het lukt mij niet. DDR1866 zie ik, en dan krijg je een latency van 12-13 erbij. Waarom? Omdat het niet sneller gemaakt wordt.

[Reactie gewijzigd door FreezeXJ op 10 maart 2015 10:26]

Er bestaan meerdere soorten geheugen fouten. Als geheugen Memtest niet overleeft is het waarschijnlijk echt kapot (of verkeerd ingesteld). Dat is wat anders dan de geheugenfouten die ECC oplost. Je kan gewoon een ECC module hebben die ook niet door Memtest komt.

Het feit dat jij 0 crashes kan toewijzen aan brak geheugen betekend dus alleen maar dat jij goed functionerend geheugen hebt, dat wil zeggen (aanname van mijn kant) unbuffered non-ECC geheugen dat niet op fouten controleert en ook niet kapot is zodat het geen fouten in Memtest produceert. Maar de fouten door omgevallen bitje's (die ECC zou kunnen verhelpen) hebben bij jouw waarschijnlijk wel tot een aantal crashes geleid.

Om nog in te gaan op de snelheid van ECC geheugen. Dat komt natuurlijk omdat er geen vraag is naar sneller geheugen en de fabrikanten volledig veilig de JEDEC specificatie volgen. Er is geen vraag naar sneller geheugen omdat de huidige doelgroep er tevreden mee is. Dat zou natuurlijk snel veranderen als elke computer uitgerust wordt met ECC geheugen.

Een fout is een fout. Dat ECC stuk kan zijn, bewijst niet dat een omgevallen bitje in normaal geheugen niet door memtest gevonden zou kunnen worden. Dat is ook niet te bewijzen, want het is niet waar. Bitjes die door een fabricagefout de neiging hebben om tijdens gebruik spontaan om te vallen, doen dat vaak bij een memtest ook al.

Natuurlijk is oorzaakanalyse van crashes een beetje wellles-nietesverhaal, want kwam die verkeerde waarde nou door een programmafout of door een hardwarefout? Ik denk op basis van eigen ervaring dat dit vaker door een programmafout komt, zeker als de hardware in het eerste deel van de badkuipcurve (faillure rate) goed getest is.

Zij zien natuurlijk wel in de statistieken dat 'ome jaap's computer een keer per dag herstart. Waar jij dan eens voor gevraagd wordt, een virus scanner er overheen gooit en schouders ophaalt, en ze dan mee verder werken. Veel crashen tikt veel meer aan dan de toevallige getriggerde bestaande bugs die je wel een tegen komt.

ECC is niet standaard, omdat het te veel geld oplevert voor bedrijven. Voor consumenten maakt ECC namelijk weinig uit, het is meer voor enthousiastelingen en bedrijven. En die groepen zijn bereid extra te betalen voor een beter systeem.
CPU's ondersteunen het, RAM is niet echt duurder, alleen moederborden worden er voor aangepast en gaan nog even 5 keer over de kop. Het werkt en ik snap dat bedrijven het doen, maar het is wel vreemd dat verzonnen obstakels je data in gevaar kunnen brengen.

Dat ze hun 'hack' Rowhammer hebben genoemd is helemaal niet zo vreemd, aangezien row hammering een werkelijk bekend design probleem is voor DRAM gebaseerde geheugen systemen op de hele hoge dichtheid en frequenties van tegenwoordig. De interferentie van schrijfacties naar een row kan de waarde van de aanliggende row omgooien. Dit komt omdat een row langzaamaan zijn lading verliest, en daarom heeft een DRAM refresh cycles om een row uit te lezen en weer vers weg te schrijven zodat de lading weer maximaal aanwezig is. Als je de naburige rows blijft schrijven vlak voordat de refresh plaatsvind heb je de grootste kans dat je een of meer bits weet om te gooien.

De oplossing is ook even simpel; deze refresh rate omhoog gooien zodat je nooit op zo'n lage lading komt dat je makkelijk te flippen bent. Blijkbaar is de standaard tuning voor de x64 systemen die ze getest hadden daar te losjes voor. Je wil ook niet een te hoge refresh rate hebben namelijk; want dan lever je weer geheugen performance in omdat af en toe je DRAM chip bezig is met een refresh cycle wanneer je hem wilt accessen en je dus moet wachten. Het probleem is wel degelijk op te lossen met bestaande hardware door een firmware update die er voor zorgt dat de refresh rate voldoende omhoog gaat, dit zou dus met een BIOS update verholpen kunnen worden.

Interessant artikel, eigenlijk zou dit nooit mogen werken en dergelijk geheugen moet naar mijn mening gewoon afgekeurd worden.

Deze test zou in memtest86 moeten komen

Deze test zou niet in MemTest moeten komen; sowieso is de tool al te downloaden om zelf je machine te checken.

Er is verder geen enkele tool ter wereld die een systeem 100% in 1x kan checken op "vulnerabilities" op zowel de hardware als de software.

Het is een vorm van een technische tekortkoming (bits hebben invloed op elkaar) die misbruikt kan worden.

De specifieke test hoeft naar mijn mening niet in memtest86, maar er zou wel iets in kunnen komen dat deze vorm van instabilitieit kan testen.

Niet duidelijk wordt, waarom deze test niet aan gangbare testsuites zoals memtest toegevoegd moet worden. Mij lijkt het juist een welkome aanvulling op de standaard testprocedures waar veel computerbouwers tools als memtest voor gebruiken. Om de vraag om te draaien: Waarom zou je een losse tool moeten gebruiken als het ook gewoon in de suite erbij kan?

Let wel: ik heb het dus specifiek over een geheugentestsuite zoals memtest. Niet over een onbestaande tool die op alle vulnerabilities van alles controleert. Het gaat hier immers niet om alles, maar gewoon om geheugen. Net als in memtest dus.

Wat ik niet snap: Als je de nabijgelegen bits flipt, dan moet je toch ook weten welke VM die bits toebehoren? Het klinkt mij nog steeds als een beetje random bitflippen (met veel vastlopers als gevolg) in plaats van gericht een VM aanvallen.

Het wordt mijns inziens pas interessant op het moment dat je bits kunt uitlezen, bijvoorbeeld om wachtwoorden en encryptiesleutels unencrypted uit te lezen.

[Reactie gewijzigd door Trommelrem op 10 maart 2015 09:57]

Ik dacht dat tegenwoordig ook juist zoveel mogelijk op random locaties in het RAM werd gedaan, dus waardoor het ook moeilijker moet worden om dit soort aanvallen te doen. Al is dat natuurlijk niet relevant als het gaat om een aanval vanuit Chrome tegen bijvoorbeeld de Chrome beveiliging.

Ontopic: erg indrukwekkend. ik denk dat er weer slechte jongens software gaan schrijven. Hopelijk word er niet al te veel misbruik gemaakt. anders moeten we DDR4 gaan gebruiken. Of ECC.
Offtopic: waarom staat er een DDR(1) Module op het plaatje

Leuk onderzoek!

Een exploit lijkt me trouwens erg lastig te maken en afhankelijk van allerlei factoren zoals het OS, toegang tot het systeem, weten wat er draait (en vooral waar & wanneer in het geheugen) en hoe je het kunt manipuleren.

uit het stuk:

When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.

Heb twee van m'n machines getest (een AMD desktop en een Intel laptop, beide zonder ECC) en er zijn geen bitjes omgevallen.
Ondanks dat er dus blijkbaar (nu nog?) aan nogal wat randvoorwaarden moet worden voldaan is het behoorlijk zorgwekkend dat software onder gebruikersrechten vrij eenvoudig het geheugen hardwarematig kan corrumperen.

Apart ... ik vraag me af of dit de deur open zet voor een jailbreak voor de XBox One, die gebruik maakt van DDR3 RAM-geheugen. Aangezien de Playstation 4 over GDDR5 geheugen beschikt zal die mogelijk niet kwetsbaar zijn voor een dergelijke hack.

Die vlieger gaat niet op, tenzij de Xbox One SODIMMS gebruikt (de laptop versie van RAM).

Ze hebben zelf een aantal laptops getest, waarvan een deel kwetsbaar was. De onderzoekers vonden nog geen kwetsbare desktops.

Edit:
Zoals te lezen op de Engelstalige wikipedia pagina bevat de Xbox One DDR3 RAM. NIET het kwatsbare SODIMM RAM dat in laptops gebruikt wordt. Je zou kunnen aannemen dat de Xbox One dus niet kwetsbaar/te hacken is.
(Aangezien Desktops tot op heden niet gehackt konden worden.)

[Reactie gewijzigd door Vickiieee op 10 maart 2015 09:48]

De kwetsbaarheid is juist van toepassing op DDR3 RAM (architectuur). Hoewel ze nog geen kwetsbare desktops gevonden hebben maak ik uit het artikel niet op dat de formfactor van het geheugen zelf invloed heeft.
Je zou ook kunnen zeggen dat de xbone mogelijk kwetsbaar is, omdat er geen DIMMs in zitten.

Sowieso zitten niet in iedere laptop SODIMMs en zitten ze wel in sommige desktops.

Ik vermoed dat de kwetsbaarheid aanwezig is in bepaalde geheugenchips die aantrekkelijk zijn voor laptops, bijvoorbeeld omdat ze compacter, of zuiniger zijn, wat dat voor de xbone betekend durf ik niet te zeggen.

Merk hierbij wel op dat er een grote kloof tussen het 'flippen van een bit' en een jailbreak zit. In deze proof of concept was alles heel netjes voorbereid dat enkel het flippen van een bit autonatisch een jailbreak zou geven. Dat is in het echte leven niet zo. Dan resulteert een geflipte bit vooral in een applicatie crash.

Immers het is immers niet veel meer dan een memory-corruptie omdat de state machien van DDR3 verstoord kan worden.

Die link had ik nog niet gelegd! Ben benieuwd of het mogelijk is om de beveiliging te kunnen omzeilen om überhaupt die instructie te kunnen sturen.

Er staat iOS tussen haakjes in jouw Wikipedia pagina.

Jailbreak wordt ook gebruikt bij Playstation:

http://en.m.wikipedia.org/wiki/PlayStation_Jailbreak

Werd voor de PS3 ook al eens gebruit, dus niet meer iOS exclusive http://nl.m.wikipedia.org/wiki/Jailbreak_(PS3)

Jailbreaken is een algemene aanduiding voor rooten.
http://en.wikipedia.org/w...e_escalation#Jailbreaking

A jailbreak is the act or tool used to perform the act of breaking out of a chroot or jail in UNIX-like operating systems[2] or bypassing digital rights management (DRM). In the former case, it allows the user to see files outside of the filesystem that the administrator intends to make available to the application or user in question. In the context of DRM, this allows the user to run arbitrarily defined code on devices with DRM as well as break out of chroot-like restrictions. The term originated with the iPhone/iOS jailbreaking community and has also been used as a term for PlayStation Portable hacking; these devices have repeatedly been subject to jailbreaks, allowing the execution of arbitrary code, and sometimes have had those jailbreaks disabled by vendor updates.

Jailbreak is gewoon een algemene term: http://nl.m.wikipedia.org/wiki/Jailbreak_(PS3)

'Niet-getroffen' lijkt me een slechte vertaling van non-vulnerable oid? Onkwetsbaar of niet-kwetsbaar lijkt me beter...

De letterlijke vertaling, zoals wat jij voorstelt, is niet altijd de beste. Getroffen en niet getroffen zijn bestaande en gangbare Nederlandse uitdrukkingen voor wat er bedoeld wordt. Onkwetsbaar komt juist gekunsteld over.

[Reactie gewijzigd door mae-t.net op 10 maart 2015 14:12]