Google har offentliggjort flere prototyper af exploits, der viser muligheden for at udnytte sårbarheder af Spectre-typen ved udførelse af JavaScript-kode i browseren, hvilket omgår tidligere tilføjede beskyttelsesmetoder. Exploits kan bruges til at få adgang til hukommelsen af processen, der håndterer webindhold i den aktuelle fane. For at teste exploitens funktionalitet er hjemmesiden leaky.page blevet startet, og koden, der beskriver logikken, er offentliggjort på GitHub.
Den foreslåede prototype er designet til at udføre angreb på systemer med Intel Core i7-6500U-processorer i et miljø med Linux og Chrome 88. For at anvende exploit i andre miljøer kræves der ændringer. Udnyttelsesmetoden er ikke specifik for Intel-processorer - efter passende tilpasning er det bekræftet, at exploiten også fungerer på systemer med CPU'er fra andre producenter, inklusive Apple M1 baseret på ARM-arkitekturen. Efter mindre justeringer fungerer exploiten også i andre operativsystemer og i andre browsere baseret på Chromium-motoren.
I et miljø baseret på standard Chrome 88 og Intel Skylake-processorer blev der opnået datalæk fra processen, der håndterer webindhold i den aktuelle Chrome-fane (renderer process) med en hastighed på 1 kilobyte pr. sekund. Der er yderligere udviklet alternative prototyper, for eksempel en exploit, der tillader at øge hastigheden på datalæk til 8 kB/s ved at reducere stabiliteten ved at bruge en performance.now()-timer med en nøjagtighed på 5 mikrosekunder (0,005 millisekunder). Der blev også forberedt en version, der fungerer med en timer-nøjagtighed på et millisekund, som kunne bruges til at organisere adgang til hukommelsen i en anden proces med en hastighed på omkring 60 byte pr. sekund.
Den offentliggjorte demonstrationskode består af tre dele. Den første del udfører kalibrering af timeren for at vurdere den tid, der er nødvendig for at udføre operationerne, der kræves for at genoprette data, der er tilbage i processorens cache som følge af spekulativ udførelse af CPU-instruktioner. Den anden del identificerer hukommelseslayoutet, der anvendes ved placering af JavaScript-arrayet.
Den tredje del udfører direkte udnyttelse af Spectre-sårbarheden for at bestemme indholdet i hukommelsen af den aktuelle proces som følge af skabelsen af betingelser for spekulativ udførelse af bestemte operationer, hvis resultater bliver kasseret af processoren efter bestemmelse af en mislykket forudsigelse, men spor af udførelsen forbliver i den samlede cache og kan genoprettes ved hjælp af metoder til bestemmelse af cacheindhold gennem sidekanaler, der analyserer ændringer i adgangstider til cachede og ikke-cachede data.
Den foreslåede teknik til udnyttelse kræver ikke præcise timere tilgængelige via API performance.now() eller understøttelse af SharedArrayBuffer-typen, som gør det muligt at oprette arrays i delt hukommelse. Eksploit inkluderer en Spectre-gadget, der udfører kontrolleret spekulativ udførelse af kode, og en sidekanalslækaganalyse, der bestemmer de data, der er cachede som følge af den spekulative udførelse.
Gadgetet er implementeret ved hjælp af et JavaScript-array, hvor der gøres et forsøg på at få adgang til et område uden for buffergrænsen, hvilket påvirker tilstanden i sprængengøringsblokken på grund af den ekstra bufferstørrelseskontrol, der tilføjes af compileren (processoren udfører spekulativt den påtænkte adgang, men ruller tilstanden tilbage efter kontrol). For at analysere cacheindholdet under forhold med utilstrækkelig timerpræcision er der foreslået en metode, der narre den anvendte cache-uændringsstrategi (Tree-PLRU) og muliggør markant at øge tidsforskellen ved at returnere værdien fra cachen i forhold til fraværet af værdien i cachen.
Det er bemærket, at Google har offentliggjort en prototype af exploiten for at demonstrere realismen af angreb ved hjælp af sårbarheder af typen Spectre og for at tilskynde webudviklere til at anvende teknikker, der minimerer risici fra sådanne angreb. Google mener, at uden en væsentlig omskrivning af den foreslåede prototype er det umuligt at skabe universelle exploits, der ikke bare er til demonstration, men også til praktisk anvendelse.
For reducing risk, website owners are encouraged to use the recently implemented headers 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, and SameSite Cookie. These mechanisms do not directly protect against attacks but allow the isolation of website data from leaking into processes where the attacker's JavaScript code might be executed (leakage occurs from the memory of the current process, which may also handle data from another site open in the same tab). The main idea is to separate the execution of the website's code from external code received from untrusted sources, such as those included via iframe.
Kilde: opennet.ru
