Google har publisert flere utnyttelsesprototyper som viser muligheten for å utnytte sårbarheter i Spectre-klassen når JavaScript-kode kjøres i nettleseren, og omgå tidligere tillagte beskyttelsesmetoder. Utnyttelser kan brukes til å få tilgang til minnet til prosessen som behandler webinnhold i gjeldende fane. For å teste driften av utnyttelsen ble nettstedet leaky.page lansert, og koden som beskriver logikken i arbeidet ble lagt ut på GitHub.
Den foreslåtte prototypen er designet for å angripe systemer med Intel Core i7-6500U-prosessorer i et miljø med Linux og Chrome 88. For å bruke utnyttelsen for andre miljøer, kreves modifikasjoner. Utnyttelsesmetoden er ikke spesifikk for Intel-prosessorer - etter passende tilpasning ble utnyttelsen bekreftet å fungere på systemer med CPUer fra andre produsenter, inkludert Apple M1 basert på ARM-arkitektur. Etter mindre justeringer er utnyttelsen også brukbar i andre operativsystemer og i andre nettlesere basert på Chromium-motoren.
I et miljø basert på standard Chrome 88- og Intel Skylake-prosessorer var det mulig å lekke data fra prosessen som var ansvarlig for å behandle nettinnhold i gjeldende Chrome-fane (gjengivelsesprosess) med en hastighet på 1 kilobyte per sekund. I tillegg har alternative prototyper blitt utviklet, for eksempel en utnyttelse som gjør det mulig, på bekostning av å redusere stabiliteten, å øke lekkasjehastigheten til 8kB/s ved bruk av performance.now()-timeren med en nøyaktighet på 5 mikrosekunder (0.005 millisekunder). ). Det ble også utarbeidet en versjon som fungerte med en timernøyaktighet på ett millisekund, som kunne brukes til å organisere tilgang til minnet til en annen prosess med en hastighet på rundt 60 byte per sekund.
Den publiserte demokoden består av tre deler. Den første delen kalibrerer tidtakeren for å estimere utførelsestiden for operasjonene som kreves for å gjenopprette data som er igjen i prosessorbufferen som et resultat av spekulativ utførelse av CPU-instruksjoner. Den andre delen bestemmer minneoppsettet som brukes ved tildeling av JavaScript-matrisen.
Den tredje delen utnytter Spectre-sårbarheten direkte for å bestemme minneinnholdet i den gjeldende prosessen som et resultat av å skape forhold for spekulativ utførelse av visse operasjoner, hvis resultat blir forkastet av prosessoren etter å ha bestemt en mislykket prediksjon, men spor av utførelse avsettes i den generelle hurtigbufferen og kan gjenopprettes ved hjelp av metoder for å bestemme innholdet i hurtigbufferen av tredjepartskanaler som analyserer endringer i tilgangstid til hurtigbufrede og ubufrede data.
Den foreslåtte utnyttelsesteknikken gjør det mulig å klare seg uten høypresisjonstidtakere tilgjengelig gjennom performance.now() API, og uten støtte for SharedArrayBuffer-typen, som tillater å lage arrays i delt minne. Utnyttelsen inkluderer Spectre-gadgeten, som forårsaker kontrollert spekulativ kjøring av kode, og en sidekanal-lekkasjeanalysator, som oppdager hurtigbufrede data innhentet under spekulativ kjøring.
Gadgeten er implementert ved hjelp av en JavaScript-matrise, der det gjøres et forsøk på å få tilgang til et område utenfor buffergrensene, noe som påvirker tilstanden til grenprediksjonsblokken på grunn av tilstedeværelsen av en bufferstørrelsessjekk lagt til av kompilatoren (prosessoren utfører spekulativt tilgangen, ser fremover, men ruller tilbake tilstanden etter kontroll). For å analysere innholdet i hurtigbufferen under forhold med utilstrekkelig tidtakernøyaktighet, har det blitt foreslått en metode som lurer Tree-PLRU-cache-utkastingsstrategien som brukes i prosessorer og tillater, ved å øke antall sykluser, å øke forskjellen i tid betydelig ved retur. en verdi fra cachen og når det ikke er noen verdi i cachen.
Det bemerkes at Google publiserte en prototype av utnyttelsen for å vise gjennomførbarheten av angrep ved bruk av sårbarheter i Spectre-klassen og for å oppmuntre nettutviklere til å bruke teknikker som minimerer risikoen fra slike angrep. Samtidig mener Google at uten betydelig omarbeiding av den foreslåtte prototypen, er det umulig å lage universelle utnyttelser som er klare ikke bare for demonstrasjon, men også for utbredt bruk.
For å redusere risikoen oppfordres nettstedeiere til å bruke de nylig implementerte overskriftene Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame- Options, X -Content-Type-Options og SameSite Cookie. Disse mekanismene beskytter ikke direkte mot angrep, men de lar deg isolere nettstedsdata fra lekkasje til prosesser der angriperens JavaScript-kode kan utføres (lekkasjen skjer fra minnet til den gjeldende prosessen, som i tillegg til angriperens kode , kan også behandle data fra et annet nettsted som er åpnet i samme fane). Hovedideen er å skille utføringen av nettstedskoden i forskjellige prosesser fra tredjepartskode mottatt fra upålitelige kilder, for eksempel inkludert gjennom en iframe.
Kilde: opennet.ru