Ethvert sikkerhedshul bør i disse tider have et godt navn, og godt nok var der ikke mange, der bed mærke i 'Row Hammer', da det først dukkede op i nogle tekniske artikler, der mest henvendte sig til chipindustrien. Men nu har sikkerhedseksperter hos Google i dén grad åbnet for Row Hammer-posen.
Opmærksomheden skyldes, at Row Hammer, som Google-folkene nu har fundet ud af at udnytte i praksis, er et angreb af en type, vi normalt ikke ser, for der er ikke tale om et sikkerhedshul i software. Derimod handler det om måden, hukommelseschip, specifikt DDR3 SDRAM, er opbygget på.
Hukommelsen er opbygget af rækker af celler, og hver celle holder på en elektrisk ladning, der bestemmer, hvorvidt informationen i den pågældende bit er 0 eller 1.
Et program har kun adgang til nogle bestemte områder i hukommelsen, mens eksempelvis styresystemet har nogle rækker i hukommelsen, som almindelige applikationer ikke kan få adgang til. Men nøjagtigt som æbler fra naboens æbletræer kan blæse over hækken og havne i din have, når det blæser nok, så kan ladningen i én række af celler sive over i celler i naborækken.
Det kan gøres ved at læse indholdet af en række af celler mange gange i træk. Håbet er så, at man kan få ændret en bit i en naborække fra eksempelvis 0 til 1, og gøre det, inden hukommelsen automatisk bliver genopfrisket.
Hukommelsescontrolleren vil normalt genopfriske værdien af cellerne med korte intervaller på eksempelvis 64 millisekunder. Men hvis man har ændret værdien, inden genopfriskningen sker, vil genopfriskningen fastholde den ændrede værdi.
På den måde kan man få lagt sin ondsindede kode ind i en del af hukommelsen, der er reserveret til styresystemet.
Der er altså tale om, at man ved at udnytte en svaghed i hardwaren kan manipulere med softwaren, og det er temmelig usædvanligt i moderne computere. Chipproducenterne er dog blevet opmærksomme på problemet og er i færd med at implementere teknikker i nyere chips, som forhindrer det. Ifølge Ars Technica skulle DDR4-hukommelse eksempelvis ikke være sårbar.
Problemet har ikke altid eksisteret i SDRAM-chips, men er først blevet muligt med de nye fremstillingsmetoder, hvor cellerne er mindre og ligger tættere. Imidlertid vil der altså være en del nyere hukommelseschips, hvor angrebet er muligt, og der ikke er bygget modforanstaltninger ind.
Servere, hvor sådan et angreb kunne være særlig interessant, kan være bedre beskyttet, hvis de anvender fejlkorrigerende hukommelseschips, ECC, men fejlkorrektionen kan kun håndtere én fejl i et område pr. genopfriskning, så denne type chip er heller ikke immun, skriver sikkerhedsekspert Graham Cluley.
Udfordringer med angreb
Der er dog udfordringer forbundet med at udnytte Row Hammer. Google-eksperterne angreb Linux-systemer, hvor de kunne få et kort over hukommelsen, men de skulle stadig gætte, hvilke rækker der var interessante at angribe. Flere styresystemer tildeler hukommelsesområderne tilfældigt efter hver genstart, hvilket gør angrebet vanskeligere men ikke umuligt.
Google-folkene fandt også ud af, at det for visse typer hukommelse var nødvendigt at banke løs på ikke bare én række ved siden af den række, der skulle ændres, men på rækkerne på begge sider.
I praksis undersøgte sikkerhedseksperterne deres angreb på 29 forskellige bærbare pc'er med Linux fremstillet mellem 2010 og 2014, og angrebet lykkedes på godt halvdelen af modellerne.
Hvordan ser det så ud med ombytning af de påvirkede ram? Det er jo ikke forbrugernes skyld, men åbenbart vores problem... Og hvad med Windows og mac? De må da mindst være lige så sårbare på dette område?
Hvordan ser det så ud med ombytning af de påvirkede ram?
Hvis den virker som en DDR3 RAM nu skal, så tror jeg ikke at du skal regne med noget ret til at kunne bytte den.
... Og hvad med Windows og mac? De må da mindst være lige så sårbare på dette område?
Det besvarer Google sikkerhedsfolkene i deres blog indlæg (1. link i v2 artiklen).
Hvordan ser det så ud med ombytning af de påvirkede ram? Det er jo ikke forbrugernes skyld, men åbenbart vores problem...
Det er ikke et angreb du behøver være nervøs for som almindelig forbruger - det kræver at angriberen har fået mulighed for at eksekvere kode på dit system, og så har du allerede tabt malware-ræset.
Der hvor Rowhammer kunne udnyttes er mod målrettede angreb, hvor privilege escalation giver mulighed for f.eks. mere stealth, eller er nødvendigt for at stikke snablen ned i interessant data.
ECC lader til at være "løsningen", eller om ikke andet så en god workaround.
ECC klodser er vist også ved at være nede i samme pris som ikke-ECC klodser, jeg køber ihvertfald ikke uden, bare sådan af rent stabilitetsmæssige grunde :)
Offtopic, men kan redaktionen ikke se at få sat en stopper for de spambots?
Hvis jeg har læst artiklen rigtigt, er det lykkedes at korrumpere et området af hukommelsen, hvor der kan formodes at ligge styresystemkode. Der er nok meget langt derfra og til dermed at kunne overtage kontrollen med systemet, som overskriften antyder, men til gengæld - og desværre - meget kort vej til at få systemet til at blive ustabilt/crashe.
Ikke helt.
Som de skriver i deres overview (egen fremhævning):
[...] We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. 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. [...]
Og uanset, så findes der folk "derude", som kan lave et exploit ud af de mest uskyldigt lignende ting.
Hvilket de også noterer sig i deres konklusion:
History has shown that issues that are thought to be “only” reliability issues often have significant security implications, and the rowhammer problem is a good example of this
Der er nok meget langt derfra og til dermed at kunne overtage kontrollen med systemet, som overskriften antyder
Nej, Peter, der er allerede proof-of-concept med fuld source.
Det er en bug man bør følge meget, meget nøje hvis man fx har med Cloud at gøre. Der er gode chancer for at RowHammer kan blive brugt til at bryde VM-isolering.
En af mine gamle bekendte har exploit detection PoC der gør brug af profiling-MSRs - god idé, men jeg ved ikke hvor stort performance overhead det har.
Det er en bug man bør følge meget, meget nøje hvis man fx har med Cloud at gøre. Der er gode chancer for at RowHammer kan blive brugt til at bryde VM-isolering.
Læg mærke til at det kun er i ældre systemer det er lykkedes og opnå bit-flips. Blogindlægget forklarer det med, at der sandsynligvis er indkorporeret counter-measures i nyere chips. Derudover, er RAMmene, der er testet non-ECC, og den korrigerende feature i ECC gør det langt sværere og detektere bit flips. Som server / cloud-ejer ville jeg derfor ikke være bekymret. Skulle jeg købe en brugt, ældre laptop eller PC ville det være noget andet.
Derudover, hverken DDR2 eller DDR4 er påvirket, så man kan altid grave en lidt ældre PC ud af gemmerne til arbejdet, hvis man har en PC der er sårbar overfor Rowhammer. Der ligger testkode fra google, som kan fortælle om ens PC er sårbar herfor.
Desuden, kan der genindføres double-sided chips med højere afstand mellem enhederne, og det ville igen gøre det sværere at udnytte fejlen.
En BIOS opdatering der sætter refresh-tiden for RAM lavere kan igen gøre det sværere at udnytte fejlen.
Selvom der ikke er ret meget at gøre ved allerede sårbare systemer, kan der dog gøres noget. HP har eksempelvis for et års tid siden leveret BIOS opdateringer til alle deres Elitebooks, hvor der bl. a. er counter-measures mod Rowhammer.
Derudover, kan man forhindre userland applikationer i at køre CLFLUSH instruktionen, hvis den ikke specifikt anvendes. Det er en hård workaround, men Google har f. eks. patchet dette i ver. 39 af Chrome.
Derudover, kan man forhindre userland applikationer i at køre CLFLUSH instruktionen, hvis den ikke specifikt anvendes. Det er en hård workaround, men Google har f. eks. patchet dette i ver. 39 af Chrome.
Hvordan?
Én ting er at google kan gøre det i NaCl verifieren, men det extender ikke til helt normal native kode - så vidt jeg ved er CLFLUSH en ikke-priviligeret instruktion, der ikke kan trappes?
Man kan gøre det på kerne-niveau. Dog kræver det lige nu at man selv kompilerer sin kerne og fjerner muligheden for at køre CLFLUSH og CLFLUSHOPT.
Men rigtigt, der er ikke et quick-fix lige nu, ikke desto mindre er det muligt.
Kerneudviklerne har overvejet det, som kan læses på linux-kernel mailgruppen.
http://lists.openwall.net/linux-kernel/2014/02/27/651
Mit bud er at der sandsynligvis kommer en fork af linux-kernel fra en af kerneudviklerne, som valgfrit kan benyttes, hvis resten af teamet ikke kan tilslutte sig at fjerne muligheden.
Ikke en super løsning, men en mulighed.
Man kan også monitorere /proc/PID/pagemap for reads.
Kontinuerlig, meget hurtig repetetiv læsning er indikation på rowhammering.
Man kan gøre det på kerne-niveau. Dog kræver det lige nu at man selv kompilerer sin kerne og fjerner muligheden for at køre CLFLUSH og CLFLUSHOPT.
Er det ikke blot capability-reporting af CLFLUSH der bliver slået fra dér? Som så gør at software der checker for caps før det anvender featuren, vil undlade at anvende instruktionen?
Malware starter næppe med at lave caps-check :)
Jeg synes ikke jeg kan se noget fra Intels instruction set manual der tyder på at man kan disable CLFLUSH, og Googles ProjectZero blog indeholder da også følgende:
Unfortunately, kernels can’t disable CLFLUSH for normal userland code. Currently, CLFLUSH can’t be intercepted or disabled, even using VMX (x86 virtualisation)
Man kan også monitorere /proc/PID/pagemap for reads.
Kontinuerlig, meget hurtig repetetiv læsning er indikation på rowhammering.
Jeg har ikke nærstuderet exploit code, men behøver man ret beset at læse pagemap mere end én gang? (Hvis det lykkes at bitflippe en PTE, kan det detectes ved at der ligger andet data ved memread, end det der lå det hukommelsesområde man legalt havde mappet?)
Man kunne dog nok argumentere for at det er de færreste normal processer der har behov for pagemap? :)
Version2 er en del af Jobfinder - Danmarks største job- og karrieresite for ingeniører og it-professionelle.
