×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Onderzoekers maken misbruik van fysieke tekortkomingen ddr3-geheugen

Door , 55 reacties

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.

Door Joost Schellevis

Redacteur

10-03-2015 • 09:26

55 Linkedin Google+

Reacties (55)

Wijzig sortering
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]

(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).
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.
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.
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.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*