CrackArmor: quando AppArmor smette di proteggere il kernel

C’è un punto preciso in cui i modelli di sicurezza smettono di essere una barriera e diventano un vettore di attacco. Non perché siano progettati male, ma perché qualcuno trova il modo di piegare le loro assunzioni di fiducia. È esattamente quello che sta succedendo con CrackArmor.

I ricercatori di Qualys hanno individuato una serie di vulnerabilità nel modulo AppArmor del kernel Linux che, a livello pratico, permettono a un utente non privilegiato di fare ciò che in teoria dovrebbe essere impossibile: uscire dal proprio perimetro, manipolare i profili di sicurezza e arrivare fino a un’escalation completa a root.

Per capire la gravità del problema bisogna partire da come funziona davvero AppArmor. Non è un semplice sistema di controllo accessi: è un meccanismo MAC (Mandatory Access Control) che lavora direttamente a livello kernel, definendo cosa un processo può o non può fare indipendentemente dall’utente che lo esegue. In altre parole, è uno dei pilastri del containment moderno, soprattutto in ambienti containerizzati.

Il problema è che questo modello si basa su una serie di confini logici, le cosiddette trust boundaries, che in CrackArmor vengono aggirate.

Le vulnerabilità – nove in totale, presenti almeno dal 2017 – sfruttano il meccanismo di sostituzione dei profili AppArmor. In condizioni normali, i profili definiscono in modo rigido le capability di un processo. Qui invece si introduce la possibilità di manipolarli utilizzando file pseudo e percorsi controllati, portando il sistema a validare configurazioni che non dovrebbero mai essere accettate.

Questo è il punto chiave: non si tratta di un semplice bug, ma di una rottura del modello di fiducia.

Una volta ottenuto questo controllo, l’attaccante può costruire una vera e propria exploit chain. Il passaggio successivo è l’interazione con strumenti privilegiati come Sudo o servizi come Postfix. Ed è qui che avviene il salto: si sfrutta un componente legittimo, con privilegi più alti, per eseguire operazioni che portano a una privilege escalation.

È il classico abuso di fiducia tra processi, ma portato a livello kernel.

Nel frattempo, sul piano più basso, si aprono anche altre superfici di attacco. Parliamo di possibilità di esaurire lo stack, generare condizioni di denial of service e, soprattutto, interferire con meccanismi come il KASLR. La lettura fuori range della memoria consente di ridurre l’entropia dello spazio di indirizzamento del kernel, facilitando ulteriormente lo sviluppo di exploit affidabili.

A quel punto il sistema è già compromesso.

Un altro aspetto critico è la gestione dei namespace. In teoria, le distribuzioni moderne – in particolare Ubuntu – limitano la creazione di user namespace per evitare escalation locali. CrackArmor consente di aggirare proprio queste restrizioni, permettendo a un utente non privilegiato di creare ambienti isolati completamente funzionali, che possono poi essere utilizzati come base per ulteriori attacchi.

E qui si rompe un altro pilastro: l’isolamento dei container.

Se puoi manipolare i profili AppArmor e contemporaneamente bypassare le restrizioni sui namespace, il confine tra host e container diventa estremamente fragile. A quel punto non stai più parlando di un exploit locale isolato, ma di una compromissione potenzialmente estendibile a intere infrastrutture.

Qualys ha scelto, almeno per ora, di non rilasciare proof-of-concept pubblici. È una decisione comprensibile. Il livello di complessità dell’exploit non è banale, ma una volta reso pubblico diventerebbe rapidamente replicabile, soprattutto in ambienti enterprise dove AppArmor è attivo di default.

E qui arriva il dato che dovrebbe far riflettere: oltre 12,6 milioni di istanze Linux aziendali utilizzano AppArmor, spesso senza una reale consapevolezza di come funzioni sotto il cofano.

Il problema riguarda tutti i kernel a partire dalla versione 4.11 e tutte le distribuzioni che utilizzano AppArmor, tra cui Ubuntu, Debian e SUSE.

Questo significa una cosa molto semplice.

Non è un bug di nicchia.

È una superficie di attacco sistemica.

E quando una vulnerabilità colpisce direttamente il layer di enforcement della sicurezza, tutto quello che sta sopra – container, servizi, applicazioni – perde parte delle sue garanzie.

La realtà è che molti sistemi considerati “hardening compliant” oggi potrebbero non esserlo affatto.

Perché quando il meccanismo che dovrebbe limitare i privilegi diventa manipolabile, il concetto stesso di isolamento smette di essere affidabile.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.