In questo articolo Indice dei contenuti 3 sezioni
Fedora sta per portare tra le sue impostazioni di default una delle difese hardware più interessanti degli ultimi anni, e la parola chiave qui è Shadow Stack. Si tratta di una protezione presente sui processori x86-64 più recenti che tiene traccia, in un’area di memoria dedicata e separata, degli indirizzi ai quali il processore deve tornare una volta terminata l’esecuzione di una funzione. Se qualcuno prova a metterci le mani sopra, la CPU se ne accorge e blocca tutto sul nascere.
L’idea iniziale era di attivarla con Fedora 45, ma i piani sono cambiati. Il Fedora Engineering and Steering Committee ha dato il via libera all’intervento spostandone però l’attivazione predefinita a Fedora 46, attesa nel 2027. Un rinvio che non toglie nulla all’importanza tecnica della cosa, anzi. La distribuzione lavora a questo obiettivo da parecchio tempo: già dal 2018 compila gran parte dei suoi pacchetti con le opzioni necessarie a inserire nei file ELF i metadati relativi alle protezioni CET. In pratica, durante la compilazione ai file eseguibili vengono aggiunte le informazioni che dicono al sistema quali funzioni di sicurezza hardware supportano.
La maggior parte dei binari distribuiti tramite i repository ufficiali contiene già quel che serve, e l’impatto sulle prestazioni previsto è trascurabile nei carichi di lavoro normali. Restano però alcuni punti da sciogliere, legati ai driver proprietari, alle estensioni Python distribuite come wheel, al codice scritto in assembly e ai componenti caricati dinamicamente. Proprio queste incompatibilità hanno pesato sullo slittamento della funzione dalla versione 45 alla 46.
Come funziona una Shadow Stack
Quando un programma richiama una funzione, il processore deve ricordarsi da dove riprendere una volta finito. Quell’indirizzo di ritorno finisce di solito nello stack del processo. Se una vulnerabilità permette di sovrascrivere la memoria, un aggressore può provare ad alterarlo e a mandare la CPU verso sequenze di istruzioni scelte apposta.
La Shadow Stack aggiunge un secondo archivio degli indirizzi di ritorno, separato da quello ordinario e protetto direttamente dall’hardware. Durante un’istruzione CALL la CPU inserisce l’indirizzo sia nello stack normale sia in quello ombra. Se in un secondo momento emergono differenze tra i due, significa che qualcosa non torna: il processore genera un errore control-protection fault invece di proseguire verso l’indirizzo compromesso.
Questa protezione nasce soprattutto per contrastare la tecnica Return-Oriented Programming, spesso abbreviata in ROP. Un attacco ROP non ha bisogno di introdurre nuovo codice eseguibile nella memoria del processo. Riutilizza invece piccole sequenze di istruzioni già presenti nel programma o nelle librerie caricate, i cosiddetti gadget, concatenandole attraverso indirizzi di ritorno manipolati.
Quali processori possono usare la protezione
Fedora indica come riferimento i processori Intel Core di undicesima generazione e successivi, più le CPU AMD basate su Zen 3 o su architetture più recenti. Il supporto reale dipende comunque dalla combinazione tra processore, firmware, kernel e modalità di esecuzione. La presenza della stringa user_shstk in /proc/cpuinfo segnala che hardware e kernel offrono il supporto per Shadow Stack nello spazio utente.
Anche la dimensione dell’area segue regole precise: per il thread principale, Linux riserva uno spazio collegato al limite dello stack ordinario, con un tetto massimo di 4 GB. La parte più delicata, però, non riguarda i programmi costruiti interamente dai repository Fedora, ma le applicazioni che caricano componenti esterni. Il loader deve verificare tutta la catena delle dipendenze e basta un solo oggetto privo della proprietà SHSTK per bloccare l’attivazione della protezione all’avvio. In quel caso il comportamento resta prudente: se una libreria incompatibile fa già parte delle dipendenze iniziali, il processo continua a funzionare senza Shadow Stack.
Una difesa importante ma non risolutiva
Va detto chiaramente che Shadow Stack non corregge buffer overflow, use-after-free o errori di gestione della memoria. Quello che fa è impedire che alcune vulnerabilità si trasformino con troppa facilità in un dirottamento del flusso di controllo basato sulla modifica degli indirizzi di ritorno. Un aggressore può comunque cercare altre vie: corrompere puntatori, sfruttare salti indiretti, manipolare dati cruciali o concatenare primitive che non dipendono dal meccanismo degli indirizzi di ritorno.
Ecco perché questa tecnologia non sostituisce le altre difese già presenti nel sistema. Deve affiancarsi ad ASLR, che rende meno prevedibile la posizione del codice in memoria, alle pagine non eseguibili, agli stack canary che aiutano a rilevare alcune sovrascritture, alla fortificazione delle librerie e alla Control-Flow Integrity. Resta poi fondamentale correggere in fretta le vulnerabilità: queste tecniche ostacolano lo sfruttamento di un errore, ma l’errore in sé rimane lì.
La scelta di Fedora conta perché sposta una protezione hardware dalla disponibilità puramente teorica all’uso di tutti i giorni. Salvo ulteriori cambi di rotta, Fedora 46 dovrebbe attivarla in automatico sui sistemi x86-64 compatibili, proteggendo i processi che presentano una catena di dipendenze interamente conforme.
