Google har publicerat flera exploateringsprototyper som visar möjligheten att utnyttja sårbarheter i Spectre-klassen vid exekvering av JavaScript-kod i webbläsaren, förbi tidigare tillagda skyddsmetoder. Exploater kan användas för att få tillgång till minnet för processen som bearbetar webbinnehåll på den aktuella fliken. För att testa driften av exploateringen lanserades webbplatsen leaky.page och koden som beskriver logiken i arbetet lades ut på GitHub.
Den föreslagna prototypen är designad för att attackera system med Intel Core i7-6500U-processorer i en miljö med Linux och Chrome 88. För att använda exploateringen för andra miljöer krävs modifieringar. Exploateringsmetoden är inte specifik för Intel-processorer - efter lämplig anpassning bekräftades utnyttjandet att fungera på system med processorer från andra tillverkare, inklusive Apple M1 baserad på ARM-arkitektur. Efter mindre justeringar är exploateringen även användbar i andra operativsystem och i andra webbläsare baserade på Chromium-motorn.
I en miljö baserad på vanliga Chrome 88- och Intel Skylake-processorer var det möjligt att läcka data från den process som ansvarade för att bearbeta webbinnehåll i den aktuella Chrome-fliken (renderarprocessen) med en hastighet av 1 kilobyte per sekund. Dessutom har alternativa prototyper utvecklats, till exempel en exploatering som gör det möjligt att, till priset av att minska stabiliteten, öka läckhastigheten till 8kB/s när timern performance.now() används med en noggrannhet på 5 mikrosekunder (0.005 millisekunder). ). En version förbereddes också som fungerade med en timernoggrannhet på en millisekund, som kunde användas för att organisera åtkomst till minnet av en annan process med en hastighet av cirka 60 byte per sekund.
Den publicerade demokoden består av tre delar. Den första delen kalibrerar timern för att uppskatta exekveringstiden för de operationer som krävs för att återställa data som finns kvar i processorcachen som ett resultat av spekulativ exekvering av CPU-instruktioner. Den andra delen bestämmer minneslayouten som används vid allokering av JavaScript-matrisen.
Den tredje delen utnyttjar Spectre-sårbarheten direkt för att bestämma minnesinnehållet i den aktuella processen som ett resultat av att skapa förutsättningar för spekulativ exekvering av vissa operationer, vars resultat kasseras av processorn efter att ha fastställt en misslyckad förutsägelse, men spår av exekvering deponeras i den allmänna cachen och kan återställas med metoder för att bestämma innehållet i cachen av tredjepartskanaler som analyserar ändringar i åtkomsttid till cachad och ocachad data.
Den föreslagna exploateringstekniken gör det möjligt att klara sig utan högprecisionstimer tillgängliga via performance.now() API, och utan stöd för typen SharedArrayBuffer, som tillåter att skapa arrayer i delat minne. Exploateringen inkluderar Spectre-gadgeten, som orsakar kontrollerad spekulativ exekvering av kod, och en sidokanalsläckanalysator, som upptäcker cachad data som erhållits under spekulativ exekvering.
Gadgeten implementeras med hjälp av en JavaScript-array, där ett försök görs att komma åt ett område utanför buffertgränserna, vilket påverkar tillståndet för grenprediktionsblocket på grund av närvaron av en buffertstorlekskontroll som lagts till av kompilatorn (processorn utför spekulativt åtkomsten, tittar framåt, men rullar tillbaka tillståndet efter kontroll). För att analysera innehållet i cachen under förhållanden med otillräcklig timernoggrannhet har en metod föreslagits som lurar Tree-PLRU cache-eviction-strategin som används i processorer och gör det möjligt att, genom att öka antalet cykler, avsevärt öka skillnaden i tid vid återkomst ett värde från cachen och när det inte finns något värde i cachen.
Det noteras att Google publicerade en prototyp av exploateringen för att visa genomförbarheten av attacker med Spectre-klasssårbarheter och för att uppmuntra webbutvecklare att använda tekniker som minimerar riskerna från sådana attacker. Samtidigt anser Google att utan betydande omarbetning av den föreslagna prototypen är det omöjligt att skapa universella exploateringar som är redo inte bara för demonstration, utan också för utbredd användning.
För att minska risken uppmuntras webbplatsägare att använda de nyligen implementerade rubrikerna 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 och SameSite Cookie. Dessa mekanismer skyddar inte direkt mot attacker, men de tillåter dig att isolera platsdata från läckage till processer där angriparens JavaScript-kod kan exekveras (läckan sker från minnet av den aktuella processen, som förutom angriparens kod , kan också bearbeta data från en annan webbplats som öppnas på samma flik). Huvudidén är att separera exekveringen av webbplatskoden i olika processer från tredjepartskod som tas emot från opålitliga källor, till exempel inkluderad via en iframe.
Källa: opennet.ru