I ricercatori del Georgia Institute of Technology, dell'Università del Michigan e dell'Università della Ruhr hanno sviluppato la tecnica di attacco iLeakage, che consente di sfruttare una vulnerabilità nei processori ARM Apple delle serie A e M aprendo una pagina appositamente progettata nel browser. I prototipi di exploit preparati dai ricercatori consentono, quando si esegue il codice JavaScript in un browser, di scoprire il contenuto dei siti aperti in altre schede. Ad esempio, hanno dimostrato la capacità di determinare il testo di una lettera aperta in una scheda Gmail, vedere YouTube cronologia e recuperare la password inserita dal gestore password LastPass nel modulo di accesso Instagram. L'attacco è applicabile al browser Safari su sistemi con macOS e qualsiasi browser sulla piattaforma iOS (le regole di Apple richiedono che tutti i browser iOS utilizzino solo il motore di sistema WebKit, comune a Safari).
Sebbene l'attacco si applichi solo ai prodotti Apple, offre un modo interessante per aggirare le restrizioni sulla risoluzione del timer nel motore WebKit, che potrebbe essere potenzialmente utile per aggirare restrizioni simili in altri browser. La vulnerabilità individuata nei chip Apple M1 e M2 ricorda la classica vulnerabilità Spectre v1 e comporta anche una perdita del contenuto della memoria durante l'esecuzione di operazioni in modalità speculativa, che, in caso di previsione errata, vengono scartate dal processore, ma le tracce della loro esecuzione vengono depositate nella cache del processore.
In questo metodo di attacco, l'esecuzione speculativa ha permesso di creare una primitiva per leggere puntatori arbitrari a 64 bit nello spazio degli indirizzi del processo responsabile del rendering dei contenuti delle pagine nel browser. Per accedere allo spazio degli indirizzi del processo in cui viene visualizzato il sito di qualcun altro, è stato utilizzato un trucco per aprire la pagina aliena esaminata in una finestra pop-up utilizzando il metodo JavaScript window.open(). In questo caso il sito non è stato aperto in un processo separato, ma nello stesso processo con il codice dell’aggressore.
Come misura di sicurezza, il motore WebKit consente a JavaScript di funzionare solo con puntatori a 35 bit compressi. Per fornire accesso all'intero spazio degli indirizzi del processo e aggirare il limite di 35 bit, i ricercatori hanno utilizzato la tecnica Type Confusion per forzare il motore JavaScript a elaborare un oggetto con un tipo errato. Durante l'elaborazione di un oggetto JavaScript appositamente progettato nel motore, vengono create condizioni che portano all'esecuzione speculativa delle istruzioni che accedono all'array.
Poiché il tipo dell'oggetto non corrisponde al tipo dell'array elaborato, in condizioni normali tali azioni vengono bloccate, quindi il codice per l'attacco Type Confusion viene inserito in un blocco condizionale "if", che in condizioni normali non viene attivato , ma viene eseguito in modalità speculativa se il processore prevede erroneamente ulteriori ramificazioni. Di conseguenza, il processore accede in modo speculativo al puntatore a 64 bit generato, ma ripristina lo stato dopo aver determinato una previsione non riuscita. In questo caso, le tracce dell'esecuzione speculativa vengono depositate nella cache condivisa e possono essere ripristinate utilizzando metodi per determinare il contenuto della cache tramite canali laterali.
Per estrarre i dati rimasti dalla cache L1 della CPU dopo operazioni speculative, l'attacco utilizza una modifica del metodo pLRU (pseudo Least Recently Used) precedentemente proposto da Google. In questo caso, il metodo originale pLRU si basa sulla misurazione dei ritardi nell'accesso ai dati, la cui differenza permette di giudicare se una determinata sequenza è o meno nella cache del processore (se i dati sono nella cache, l'operazione viene eseguita più velocemente, e in caso contrario, più lentamente). Per proteggersi dal sondaggio della cache del processore nei browser moderni, la precisione del timer è significativamente ridotta a un livello che non consente di rilevare differenze.
Per superare la limitazione della precisione del timer nell'attacco iLeakage, viene proposta una tecnica per determinare la presenza o l'assenza di dati nella cache utilizzando una race condition. L'essenza del metodo è avviare contemporaneamente due thread: quello principale e quello di riferimento. Un thread di riferimento include una sequenza di istruzioni che vengono eseguite in un momento di riferimento specifico. All'inizio dell'esecuzione del thread di riferimento, una variabile condivisa con il thread principale viene impostata su 1 e, dopo l'esecuzione delle istruzioni, la variabile viene reimpostata su zero. Pertanto, una variabile condivisa ha il valore 1 solo per un certo breve periodo.
Il thread principale avvia un ciclo per determinare i dati nella cache utilizzando il metodo pLRU. Un segno della presenza o dell'assenza di dati controllati nella cache non è la misurazione del tempo da parte del timer, ma lo stato della variabile congiunta dopo il controllo. Se la variabile ha un valore pari a 1, l'operazione è stata completata più velocemente rispetto al codice di riferimento è stato eseguito in un thread parallelo, ad es. i dati sono stati forniti dalla cache. Se la variabile contiene il valore 0, l'operazione ha richiesto un tempo relativamente lungo per essere completata a causa della mancanza di dati nella cache e il codice di riferimento nel thread parallelo ha avuto il tempo di essere completamente elaborato.
L'accuratezza del metodo proposto per determinare il contenuto della cache varia dal 90% al 99% e le prestazioni della determinazione dei dati vanno da 23 a 34 byte al secondo, a seconda del processore e del dispositivo. Prima di effettuare l'attacco è necessaria la calibrazione del codice di riferimento, che richiede circa cinque minuti. Una volta completata la calibrazione per il sistema attuale, sono necessari circa 64 secondi per estrarre una stringa di 30 caratteri.
Inoltre, possiamo notare la pubblicazione di un prototipo di exploit che sfrutta la vulnerabilità Zenbleed nei processori AMD basati sulla microarchitettura Zen2 per estrarre i dati elaborati in altri processi quando si apre una pagina con l'exploit in Chrome. Oltre alla vulnerabilità Zenbleed (CVE-2023-20593), l'exploit coinvolge anche la vulnerabilità CVE-2023-3079 nel motore V8, risolta in Chrome 115.
Fonte: opennet.ru