Google har udgivet adskillige udnyttelsesprototyper, der viser muligheden for at udnytte Spectre-klassens sårbarheder, når JavaScript-kode udføres i en browser, uden at tidligere tilføjede beskyttelsesmetoder. Udnyttelse kan bruges til at få adgang til hukommelsen for en proces, der behandler webindhold i den aktuelle fane. For at teste driften af udnyttelsen blev webstedet leaky.page lanceret, og koden, der beskriver logikken i arbejdet, blev lagt på GitHub.
Den foreslåede prototype er designet til at angribe systemer med Intel Core i7-6500U-processorer i et Linux- og Chrome 88-miljø. Der kræves ændringer for at anvende udnyttelsen til andre miljøer. Udnyttelsesmetoden er ikke specifik for Intel-processorer - efter passende tilpasning blev udnyttelsen bekræftet til at fungere på systemer med CPU'er fra andre producenter, inklusive Apple M1 baseret på ARM-arkitekturen. Efter mindre justeringer fungerer udnyttelsen også på andre operativsystemer og andre browsere baseret på Chromium-motoren.
I et miljø baseret på standard Chrome 88- og Intel Skylake-processorer blev data lækket fra den proces, der er ansvarlig for behandling af webindhold i den aktuelle Chrome-fane (renderer-proces), med en hastighed på 1 kilobyte pr. sekund. Derudover blev alternative prototyper udviklet, for eksempel en udnyttelse, der tillader, på bekostning af at reducere stabiliteten, at øge lækagehastigheden til 8kB/s, når du bruger performance.now() timeren med en nøjagtighed på 5 mikrosekunder (0.005 millisekunder) . Der blev også udarbejdet en variant, der arbejder 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 bytes i sekundet.
Den offentliggjorte demokode består af tre dele. Den første del kalibrerer timeren for at estimere udførelsestiden for de operationer, der kræves for at gendanne data, der er tilbage i processorcachen som et resultat af spekulativ udførelse af CPU-instruktioner. Den anden del bestemmer hukommelseslayoutet, der bruges ved tildeling af JavaScript-arrayet.
Den tredje del udnytter Spectre-sårbarheden direkte til at bestemme indholdet af hukommelsen af den aktuelle proces som et resultat af at skabe betingelser for spekulativ udførelse af visse operationer, hvis resultat kasseres af processoren efter at have bestemt en mislykket forudsigelse, men eksekvering spor deponeres i den generelle cache og kan gendannes ved hjælp af metoder til at bestemme indholdet af cachen af tredjepartskanaler, der analyserer ændringer i adgangstid til cachelagrede og ikke-cachelagrede data.
Den foreslåede udnyttelsesteknik eliminerer de højpræcisionstimere, der er tilgængelige via performance.now() API'et og uden understøttelse af SharedArrayBuffer-typen, som tillader oprettelse af arrays i delt hukommelse. Udnyttelsen inkluderer Spectre-gadget'en, som forårsager kontrolleret udførelse af spekulativ kode, og en side-kanal lækanalysator, som bestemmer de data, der opnås under den spekulative eksekvering, der kom ind i cachen.
Gadgetten 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 bufferens grænser, hvilket påvirker tilstanden af grenforudsigelsesblokken på grund af bufferstørrelseskontrollen tilføjet af compileren (processoren, der ser fremad , udfører spekulativt adgangen, men ruller tilstanden tilbage efter kontrollen). For at analysere indholdet af cachen under forhold med utilstrækkelig timer-nøjagtighed foreslås en metode, der bedrager Tree-PLRU-cache-eviction-strategien, der bruges i processorer og tillader, ved at øge antallet af cyklusser, at øge forskellen i tid, når en returnering af en værdi fra cachen, og når der ikke er nogen værdi i cachen.
Det bemærkes, at Google udgav en prototypeudnyttelse for at vise realismen i angreb ved hjælp af sårbarheder fra Spectre-klassen og for at opmuntre webudviklere til at bruge teknikker, der minimerer risiciene fra sådanne angreb. Samtidig mener Google, at uden en væsentlig revision af den foreslåede prototype er det umuligt at skabe universelle udnyttelser, der ikke kun er klar til demonstration, men også til udbredt brug.
For at mindske risikoen opfordres webstedsejere til at bruge den nyligt implementerede 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-cookies. Disse mekanismer beskytter ikke direkte mod angreb, men tillader isolering af webstedsdata fra lækage ind i processer, hvori angriberens JavaScript-kode kan udføres (lækagen opstår fra hukommelsen af den aktuelle proces, hvori, ud over angriberens kode, data fra et andet websted åbnet i samme fane). Hovedideen er i forskellige processer at adskille eksekveringen af webstedskoden fra tredjepartskode opnået fra upålidelige kilder, for eksempel inkluderet gennem en iframe.
Kilde: opennet.ru