La soluzione alle vulnerabilità SLAP e FLOP dei processori Apple Silicon è… Asahi Linux?

Se qualche settimana fa vi abbiamo raccontato della serie di patch per il Kernel Linux che farà ordine (una volta per tutte) sulle mitigazioni ai bug delle CPU, le notizie che riguardano i processori della serie Apple Silicon – vittima di attacchi informatici micro-architetturali – raccontano come il problema di queste vulnerabilità sia trasversale e, soprattutto, ancora attuale.

Questa nuova ondata di vulnerabilità consente di accedere ad aree di memoria sensibili e permette agli attaccanti di leggere dati a cui non dovrebbero avere accesso.

Il team di sicurezza del Georgia Institute of Technology and Ruhr University Bochum ha presentato due paper che scendono nel dettaglio per questo tipo di vulnerabilità della famosa serie dei processori di Apple. Questi attacchi fanno parte della categoria Side Channel Attacks, ovvero una classe di attacchi che agisce ed estrae dati grazie ad informazioni ottenute indirettamente tramite il processore (ad esempio misurando il tempo di esecuzione di una parte di codice oppure accedendo ad aree di memoria che il processore mette a disposizione dei programmatori).

Nel mese di gennaio 2025 sono stati rilasciati i citati paper e diversi Proof Of Concept che si concentrano su una vulnerabilità side channel di tipo speculative execution per alcuni processori della serie M e della serie A.
I due attacchi sono denominati rispettivamente SLAP e FLOP e permettono di accedere ad aree di memoria riservate e che non dovrebbero essere condivise tra processi.
I processori Apple come detto in precedenza, non sono nuovi a questo tipo di vulnerabilità. Gli attacchi SLAP e FLOP sono stati già analizzati rispettivamente a Marzo 2024 e a Settembre 2024.

SLAP: Data Speculation Attacks via Load Address Prediction

SLAP è un attacco di tipo speculative execution nato a causa dell’ottimizzazione fatta da Apple alle dipendenze di dato. In particolare, alcuni processori come M2 (presente su molti MacBook) e A15 (presente su alcuni modelli della serie di iPhone 13 e iPhone 14) presentano un meccanismo di Load Address Predictor (LAP) che cerca di indovinare quali saranno gli indirizzi di memoria da cui dovranno essere presi i prossimi dati richiesti dal processore, basandosi sui pattern precedenti di accesso alla memoria, una specie di Branch Predictor sullo stile di quanto già visto sui processori più moderni.

Sfruttando l’attacco SLAP gli attaccanti sono riusciti a leggere delle stringhe salvate in memoria. Tramite l’accesso non privilegiato ad un processo e l’abuso del LAP, che quando sbaglia l’indirizzo da caricare permette l’accesso a delle aree di memoria potenzialmente private, l’attaccante può infatti accedere a dati non autorizzati, come dimostrato in questa Proof Of Concept.

FLOP: False Load Output Predictions

L’attacco FLOP è un altro attacco di tipo speculative execution che rende vulnerabili processori di Apple come i nuovi M3 e A17, montati rispettivamente su MacBook Pro 2023 e iPhone 15. In questo caso è possibile sfruttare un Load Value Predictor (LVP), ovvero un meccanismo che cerca di predire il prossimo dato che il processore potrebbe voler utilizzare.

Questa volta è possibile sfruttare la vulnerabilità grazie agli errori commessi dall’LVP. L’attaccante in questo caso cerca di indurre in errore il predittore, che in molteplici esecuzioni riuscirà a stampare aree di memoria potenzialmente sensibili, come ad esempio delle password o dei valori privati di altri processi. Sfruttando l’attacco SLAP gli attaccanti sono riusciti a leggere delle mail sul browser Firefox, come evidenziato in questa Proof Of Concept.

Al momento di pubblicazione di questo articolo, Apple non ha rilasciato una mitigazione. Questo vuol dire che le vulnerabilità potrebbero essere sfruttate “as is” o come vettori di attacco per attacchi ancora più complessi.

E se la soluzione fosse Asahi Linux?

E per quanto riguarda la nota distribuzione open source Asahi Linux per Mac con processore ARM di cui abbiamo già discusso in altri articoli? Gli attacchi di tipo speculative execution, ma più in generale gli attacchi di tipo Side Channel, dipendono più dalla micro-architettura del processore e dall’ISA (Instruction Set Architecture) che dal sistema operativo, ma come ultima protezione si può cercare di implementare una mitigazione lato kernel.
Hector Martin, lead developer del progetto Asahi, ha cercato di riprodurre gli attacchi illustrati nei paper SLAP e FLOP ed ha commentato su Mastodon in questo modo le due vulnerabilità:

As the researchers noted, FLOP is mitigated by the ARM ISA’s DIT bit, which is a bit that requests data-independent timing. That means it’s working as intended. That’s the bit you’re supposed to flip when executing code where timing could leak secret information, and the FLOP PoC indeed ends up recovering data through cache timing (it’s always this with speculation bugs).

Come hanno osservato i ricercatori, il FLOP è mitigato dal bit DIT dell’ISA ARM, che è un bit che richiede una temporizzazione indipendente dai dati. Ciò significa che funziona come previsto. È il bit che si dovrebbe attivare quando si esegue codice in cui la temporizzazione potrebbe far trapelare informazioni segrete, e il PoC FLOP finisce effettivamente per recuperare i dati attraverso la temporizzazione della cache (è sempre così con i bug di speculazione).

Hector Martin ribadisce poi che è fondamentale che gli applicativi (come ad esempio i browser) implementino mitigazioni come il DIT bit e che scrivendo codice sicuro questa vulnerabilità sia facilmente mitigabile.

Per quanto riguarda l’attacco SLAP, inizialmente il kernel developer non era riuscito a riprodurne la PoC, ma in seguito, con un post su Mastodon, ha affermato:

HA, so here’s why I couldn’t reproduce SLAP.
m1n1 accidentally turns off the SSBS bit in PSTATE on EL0 calls. It defaults to 1 on CPU startup.
Flipping that bit to 0 disables the speculation and fixes the behavior. My test code was accidentally mitigating the problem.

Ecco perché non sono riuscito a riprodurre lo SLAP.
m1n1 disattiva accidentalmente il bit SSBS in PSTATE sulle chiamate EL0. Il valore predefinito è 1 all’avvio della CPU.
Se si porta il bit a 0 si disabilita la speculazione e si risolve il problema. Il mio codice di test attenuava accidentalmente il problema.

In pratica, alcune righe di codice usate come “test” nel bootloader m1n1 hanno accidentalmente mitigato la vulnerabilità SLAP.

Le vulnerabilità SLAP e FLOP sono quindi mitigate: SLAP viene accidentalmente mitigata su Asahi grazie al SSBS bit e FLOP può essere mitigata utilizzando il DIT bit.

Al giorno d’oggi i processori sono sempre più performanti, utilizzano sempre più memoria cache e sono migliorati nella loro micro-architettura ad ogni generazione.
Sia su soluzioni open-source, come nei processori RISC-V, sia in soluzioni affermate e consolidate, come i classici processori AMD e Intel a istruzioni complesse, fino ad arrivare ai processori super-proprietari di Apple, la tendenza ad “andare più veloce” tralascia l’aspetto della sicurezza “low level” che molte volte si è rivelata letale per la sicurezza del sistema.

Un caso è quello dei vecchi e noti attacchi Spectre e Meltdown che hanno causato non pochi problemi in molti sistemi virtualizzati (e non) nel mondo.