Forskare från Georgia Institute of Technology, University of Michigan och Ruhr University har utvecklat attacktekniken iLeakage, som gör det möjligt att utnyttja en sårbarhet i Apples ARM-processorer i A- och M-serien genom att öppna en specialdesignad sida i webbläsaren. Exploateringsprototyper som utarbetats av forskarna gör det möjligt att när du kör JavaScript-kod i en webbläsare ta reda på innehållet på webbplatser som öppnats på andra flikar. De visade till exempel möjligheten att bestämma texten i ett brev som öppnas på en Gmail-flik, se YouTube historik och hämta lösenordet som infogats av LastPass lösenordshanteraren i inloggningsformuläret. Instagram. Attacken är tillämplig på webbläsaren Safari på system med macOS och alla webbläsare på iOS-plattformen (Apple-regler kräver att alla iOS-webbläsare endast använder WebKit-systemmotorn, som är gemensam för Safari).
Även om attacken bara gäller Apple-produkter, erbjuder den ett intressant sätt att kringgå begränsningar för timerupplösning i WebKit-motorn, vilket potentiellt kan vara användbart för att kringgå liknande begränsningar i andra webbläsare. Sårbarheten som identifierats i Apple M1- och M2-chippen påminner om den klassiska Spectre v1-sårbarheten och leder även till ett läckage av minnesinnehåll när man utför operationer i spekulativt läge, som, vid en felaktig förutsägelse, kasseras av processorn, men spår av deras exekvering deponeras i processorcachen.
I denna attackmetod gjorde spekulativ exekvering det möjligt att skapa en primitiv för att läsa godtyckliga 64-bitars pekare i adressutrymmet för processen som ansvarar för att rendera innehållet på sidor i webbläsaren. För att få tillgång till adressutrymmet för processen där någon annans webbplats renderas användes ett trick för att öppna den främmande sidan som undersöks i ett popup-fönster med JavaScript-metoden window.open() . I det här fallet öppnades webbplatsen inte i en separat process, utan i samma process med angriparens kod.
Som en säkerhetsåtgärd tillåter WebKit-motorn endast JavaScript att fungera med packade 35-bitarspekare. För att ge tillgång till hela processens adressutrymme och kringgå 35-bitarsgränsen använde forskarna Type Confusion-tekniken för att tvinga JavaScript-motorn att bearbeta ett objekt med en felaktig typ. Vid bearbetning av ett specialdesignat JavaScript-objekt i motorn skapas förhållanden som leder till spekulativ exekvering av instruktioner som kommer åt arrayen.
Eftersom typen av objekt inte matchar typen av array som bearbetas, blockeras sådana åtgärder under normala förhållanden, så koden för Type Confusion-attacken placeras i ett villkorligt "om"-block, som inte aktiveras under normala förhållanden , men exekveras i spekulativt läge om processorn felaktigt förutsäger ytterligare förgrening. Som ett resultat kommer processorn spekulativt åt den genererade 64-bitarspekaren, men rullar tillbaka tillståndet efter att ha fastställt en misslyckad förutsägelse. I detta fall deponeras spår av spekulativ exekvering i den delade cachen och kan återställas med metoder för att bestämma innehållet i cachen genom sidokanaler.
För att extrahera data från CPU L1-cachen som finns kvar efter spekulativa operationer använder attacken en modifiering av pLRU-metoden (pseudo Least Recently Used) som tidigare föreslagits av Google. I det här fallet är den ursprungliga pLRU-metoden baserad på att mäta fördröjningar vid åtkomst till data, vars skillnad gör det möjligt att bedöma om en viss sekvens finns i processorcachen eller inte (om data cachelagras utförs operationen snabbare, och om inte, långsammare). För att skydda mot processorcache-probing i moderna webbläsare reduceras timerns noggrannhet avsevärt till en nivå som inte tillåter detektering av skillnader.
För att övervinna begränsningen av timernoggrannheten i iLeakage-attacken, föreslås en teknik för att bestämma närvaron eller frånvaron av data i cachen med hjälp av ett tävlingstillstånd. Kärnan i metoden är att samtidigt lansera två trådar - huvudet och referensen. En referenstråd inkluderar en sekvens av instruktioner som exekveras vid en specifik referenstidpunkt. Allra i början av exekveringen av referenstråden sätts en variabel som delas med huvudtråden till 1, och efter att instruktionerna exekveras återställs variabeln till noll. En delad variabel har alltså bara värdet 1 under en viss kort tid.
Huvudtråden initierar en cykel för att bestämma data i cachen med användning av pLRU-metoden. Ett tecken på närvaro eller frånvaro av kontrollerade data i cachen är inte tidsmätningen av timern, utan tillståndet för den gemensamma variabeln efter kontroll. Om variabeln har ett värde på 1, så utfördes operationen snabbare än referenskoden i en parallell tråd, dvs. data serverades från cachen. Om variabeln innehåller värdet 0, tog operationen relativt lång tid att slutföra på grund av bristen på data i cachen, och referenskoden i den parallella tråden hann bli fullständigt bearbetad.
Noggrannheten för den föreslagna metoden för att bestämma cache-innehåll sträcker sig från 90 % till 99 %, och prestandan för databestämning ä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. När kalibreringen är klar för det aktuella systemet tar det cirka 64 sekunder att extrahera en sträng på 30 tecken.
Dessutom kan vi notera publiceringen av en prototypexploatering som använder Zenbleed-sårbarheten i AMD-processorer baserad på Zen2-mikroarkitekturen för att extrahera data som bearbetats i andra processer när man öppnar en sida med exploateringen i Chrome. Utöver Zenbleed-sårbarheten (CVE-2023-20593) involverar exploateringen även CVE-2023-3079-sårbarheten i V8-motorn, fixad i Chrome 115.
Källa: opennet.ru