Forskare från Georgia Institute of Technology, University of Michigan och Ruhruniversitetet har utvecklat attacktekniken iLeakage, som utnyttjar en sårbarhet i Apples ARM-processorer i A- och M-serien genom att öppna en specialdesignad sida i en webbläsare. De prototyper som forskarna har tagit fram gör det möjligt att, när JavaScript-kod körs i en webbläsare, ta reda på innehållet på webbplatser som öppnats i andra flikar. De visade till exempel möjligheten att identifiera texten i ett brev som öppnats i en flik med Gmail, visa YouTube-historik och extrahera ett lösenord som angetts av lösenordshanteraren LastPass i Instagrams inloggningsformulär. Attacken är tillämplig på Safari-webbläsaren på macOS-system och alla webbläsare på iOS-plattformen (Apples regler kräver att alla iOS-webbläsare endast använder WebKit-systemmotorn, vilket är vanligt med Safari).
Även om attacken endast är tillämplig på Apple-produkter, erbjuder den ett ganska intressant sätt att kringgå begränsningarna för timerupplösning i WebKit-motorn, vilket potentiellt skulle kunna vara användbart för att kringgå liknande begränsningar i andra webbläsare. Sårbarheten som finns i Apples M1- och M2-chip liknar den klassiska Spectre v1-sårbarheten och leder också till en minnesläcka när operationer utförs i spekulativt läge, vilka kasseras av processorn vid en felaktig förutsägelse, men spår av deras exekvering fastnar i processorns cache.
I den aktuella attackmetoden möjliggjorde spekulativ exekvering skapandet av en primitiv för att läsa godtyckliga 64-bitars pekare i adressutrymmet för den process som ansvarar för att rendera innehållet på sidor i webbläsaren. För att få åtkomst till adressutrymmet för den process där den främmande webbplatsen renderas användes ett trick där den studerade främmande sidan öppnades i ett popup-fönster med hjälp av JavaScript-metoden window.open(). I det här fallet öppnades webbplatsen inte i en separat process, utan i samma process som angriparens kod.
Som en av säkerhetsåtgärderna i WebKit-motorn tillåts JavaScript endast fungera med packade 35-bitarspekare. För att organisera åtkomst till hela processens adressutrymme och kringgå 35-bitarsbegränsningen använde forskarna typförvirringstekniken, som gör det möjligt att tvinga JavaScript-motorn att bearbeta ett objekt med en felaktig typ. Vid bearbetning av ett specialformaterat JavaScript-objekt skapar motorn förhållanden som leder till spekulativ exekvering av instruktioner som kommer åt arrayen.
Eftersom objekttypen inte matchar typen av arrayen som bearbetas, blockeras sådana åtgärder under normala förhållanden, så koden för Type Confusion-attacken placeras i ett villkorligt "if"-block, vilket inte aktiveras under normala förhållanden, utan exekveras i spekulativt läge när processorn felaktigt förutspår ytterligare förgrening. Som ett resultat kommer processorn spekulativt åtkomst till den genererade 64-bitarspekaren, men återställer tillståndet efter att ha fastställt den misslyckade förutsägelsen. I detta fall lagras spår av spekulativ exekvering i den allmänna cachen och kan återställas med hjälp av metoder för att bestämma cacheinnehållet via sidokanaler.
För att extrahera data från CPU L1-cachen som återstår efter spekulativ exekvering av operationer använder attacken en modifiering av pLRU-metoden (pseudo Least Recently Used) som tidigare föreslagits av Google. Den ursprungliga pLRU-metoden är kopplad till att mäta fördröjningar i åtkomst till data, vars skillnad gör det möjligt att bedöma om en viss sekvens finns i processorcachen (om data cachas utförs operationen snabbare, och om inte, långsammare). För att skydda mot avsökning av processorcachen i moderna webbläsare har timerns noggrannhet reducerats avsevärt till en nivå som inte tillåter att skillnader upptäcks.
För att övervinna begränsningen i timernoggrannheten i iLeakage-attacken föreslås en teknik som gör det möjligt att bestämma närvaron eller frånvaron av data i cachen med hjälp av ett kappvillkor. Metodens kärna är den samtidiga lanseringen av två trådar - huvudtråden och referenstråden. Referenstråden inkluderar en sekvens av instruktioner som exekveras under en viss referenstid. Alldeles i början av exekveringen av referenstråden sätts en variabel som delas med huvudtråden till 1, och efter att instruktionerna har exekverats nollställs variabeln. Således har den delade variabeln värdet 1 endast under en viss kort tid.
I huvudtråden initieras en cykel för att bestämma data i cachen med hjälp av pLRU-metoden. Närvaron eller frånvaron av data som kontrolleras i cachen indikeras inte av timermätningen, utan av tillståndet för den delade variabeln efter kontrollen. Om variabeln har värdet 1, slutfördes operationen snabbare än referenskoden i den parallella tråden exekverades, d.v.s. data returnerades från cachen. Om variabeln innehåller värdet 0, exekverades operationen relativt långsamt på grund av avsaknaden av data i cachen och referenskoden i den parallella tråden hann exekveras helt.
Noggrannheten hos den föreslagna metoden för att bestämma cacheinnehållet är från 90 % till 99 %, och prestandan för datadetektering är från 23 till 34 byte per sekund, beroende på processor och enhet. Innan attacken utförs krävs kalibrering av referenskoden, vilket tar cirka fem minuter. Efter att kalibreringen är klar tar det cirka 64 sekunder för det aktuella systemet att extrahera en sträng på 30 tecken.
Dessutom är det värt att notera publiceringen av en prototyp av ett exploit som använder Zenbleed-sårbarheten i AMD-processorer baserade på Zen2-mikroarkitekturen för att extrahera data som bearbetats i andra processer när en sida med exploiten öppnas i Chrome. Förutom Zenbleed-sårbarheten (CVE-2023-20593) använder exploiten även CVE-2023-3079-sårbarheten i V8-motorn, vilken åtgärdades i Chrome 115.
Källa: opennet.ru
