Mar 16, 2026 Redazione Approfondimenti, In evidenza, News, RSS, Vulnerabilità, Vulnerabilità
Secondo una ricerca di Qualys, il pacchetto di vulnerabilità individuato in AppArmor consente a un utente locale non privilegiato di manipolare i profili di sicurezza, aggirare restrizioni del kernel, arrivare all’elevazione di privilegi fino a root e indebolire l’isolamento dei container. Il problema, inoltre, non è confinato a un caso di laboratorio marginale: Qualys afferma che la falla esiste dal kernel Linux v4.11, quindi dal 2017, e riguarda distribuzioni in cui AppArmor è abilitato o integrato, tra cui Ubuntu, Debian e SUSE.
L’impatto potenziale è molto ampio. Qualys stima che oltre 12,6 milioni di sistemi enterprise Linux operino con AppArmor abilitato di default, e questo rende CrackArmor una vulnerabilità particolarmente rilevante per server, ambienti cloud, cluster Kubernetes, infrastrutture edge e workload containerizzati. Il fatto che non siano ancora stati assegnati identificativi CVE non deve trarre in inganno: sia Qualys sia Canonical chiariscono che si tratta di vulnerabilità reali, già corrette o in fase di distribuzione tramite aggiornamenti kernel e mitigazioni userspace, ma non ancora formalmente catalogate con un ID pubblico.
Il cuore del problema: un “confused deputy” che trasforma AppArmor da barriera a punto d’ingresso
Il difetto più importante individuato da Qualys è una vulnerabilità strutturale definita “confused deputy”. In pratica, un utente locale senza privilegi può sfruttare il comportamento di componenti fidati del sistema per caricare, sostituire o rimuovere profili AppArmor arbitrari attraverso pseudo-file come /sys/kernel/security/apparmor/.load, .replace e .remove. Da qui si aprono diversi scenari: si possono rimuovere profili che proteggono servizi chiave come cupsd o rsyslogd, si possono caricare profili “deny all” capaci di bloccare un servizio come sshd, oppure si possono creare profili che aggirano le restrizioni sui namespace utente, restituendo a un account locale capacità che non dovrebbe avere.
È questo il tassello che rende pericolose anche le altre falle. Canonical spiega che su host senza workload containerizzati lo sfruttamento richiede normalmente la cooperazione di un’applicazione privilegiata, ad esempio un binario setuid come SU, mentre in ambienti che eseguono container potenzialmente ostili le vulnerabilità del kernel AppArmor possono teoricamente portare anche a container escape, senza bisogno di una controparte privilegiata in userspace. Canonical precisa che questa evasione non è stata dimostrata pubblicamente nella pratica al momento della pubblicazione, ma il rischio teorico esiste e per questo raccomanda l’applicazione degli aggiornamenti kernel come remediation primaria.
Tutte le vulnerabilità di CrackArmor, una per una
Il pacchetto CrackArmor comprende nove vulnerabilità nel codice del kernel AppArmor. Qualys ne descrive in dettaglio alcune e cita le altre attraverso la serie di patch upstream associate alla correzione. La prima è il già citato confused deputy, che permette a un utente non privilegiato di gestire profili AppArmor arbitrari e quindi di abbassare le difese del sistema o di creare le condizioni per exploit più avanzati. Qualys lo definisce la vulnerabilità fondamentale su cui poggia l’intera catena di attacco.
La seconda è una out-of-bounds read in unpack_pdb, corretta dalla patch “validate DFA start states are in bounds in unpack_pdb”. In sostanza, il parser dei DFA di AppArmor può accedere a memoria fuori dai limiti previsti. Qualys non la espande quanto altre, ma la include espressamente tra le nove falle corrette.
La terza è una memory leak in verify_header, anch’essa citata direttamente nella lista delle patch. Non è la più pericolosa della serie in termini di exploitability immediata, ma resta parte del pacchetto di problemi che indeboliscono l’affidabilità del parser dei profili AppArmor.
La quarta è una uncontrolled recursion nel meccanismo di rimozione dei profili. Qualys spiega che la rimozione di sottoprofili profondamente annidati può portare a esaurimento dello stack del kernel e quindi a kernel panic e crash completo del sistema. Secondo i ricercatori, questo specifico bug sembra essere “solo” una vulnerabilità di denial of service, non una LPE diretta, perché la protezione CONFIG_VMAP_STACK impedirebbe il salto oltre la guard page dello stack. Resta però un problema molto serio per la disponibilità dei sistemi Linux esposti a utenti locali non fidati.
La quinta è una out-of-bounds read in match_char(), descritta da Qualys nel dettaglio. Quando AppArmor confronta un pathname con una propria espressione regolare, un bug nella macro può far avanzare il puntatore oltre il byte nullo terminale e quindi oltre il buffer allocato. Qualys mostra come questa condizione possa essere trasformata in una disclosure di memoria del kernel, fino a circa 64 KB, compresi puntatori del kernel randomizzati da KASLR. Questo significa che l’exploit non si limita a leggere memoria in modo improprio, ma può indebolire significativamente le mitigazioni di randomizzazione degli indirizzi, semplificando altre catene di attacco.
La sesta è un’ulteriore vulnerabilità di out-of-bounds read e write in verify_dfa(), dovuta all’assenza di un controllo dei limiti sulla tabella DEFAULT. Anche questa è citata direttamente nella serie di patch. È una falla rilevante perché combina lettura e scrittura fuori dai limiti all’interno del meccanismo di verifica dei DFA, quindi nel cuore del parser di policy di AppArmor.
La settima è una double-free di ns_name in aa_replace_profiles(). Qualys la descrive come sfruttabile in cache slab comprese tra kmalloc-8 e kmalloc-256, e la dimostra almeno su Debian 13.1 come catena che porta a privilegi root completi, nonostante la presenza della mitigazione CONFIG_SLAB_BUCKETS. Il fatto che la doppia liberazione coinvolga percorsi centrali della gestione dei namespace AppArmor la rende particolarmente preziosa per chi costruisce exploit affidabili.
L’ottava è una vulnerabilità di infinite loop nella verifica del differential encoding, corretta dalla patch “fix differential encoding verification”. È meno spettacolare della LPE, ma può contribuire a blocchi e instabilità del kernel o a condizioni che facilitano denial of service in fase di parsing delle policy.
La nona è una use-after-free legata a una race su rawdata, corretta con due patch distinte: una sulla dereferenziazione di rawdata e una sulla corsa tra liberazione dei dati e accesso dal filesystem. Questa è una delle falle più gravi dell’intero pacchetto. Qualys spiega che l’oggetto aa_loaddata, allocato nella cache kmalloc-192, può essere liberato e riutilizzato in una finestra di race che gli attaccanti riescono ad allargare sfruttando altre primitive disponibili. Il risultato, secondo i PoC dei ricercatori, è una LPE fino a root pieno almeno su Ubuntu 24.04.3 e Debian 13.1, persino in presenza di mitigazioni come CONFIG_RANDOM_KMALLOC_CACHES.
Le catene di exploit: come si passa da un utente locale a root
Il punto più inquietante del lavoro di Qualys è che le falle non restano isolate. Il team mostra come il confused deputy renda possibile caricare profili arbitrari e come questi profili possano poi essere usati per creare condizioni favorevoli a exploit in userspace o in kernel space. In uno scenario host, Qualys dimostra che una policy opportunamente costruita può negare a sudo una capability specifica e creare una situazione “fail-open” con l’integrazione mail di Postfix, fino a ottenere una shell root. Canonical, da parte sua, conferma l’esistenza di una vulnerabilità separata in sudo, attivabile tramite la funzione di email notification, che può portare a local privilege escalation quando concatenata con le falle AppArmor e con il comportamento di su.
C’è poi il fronte dei namespace e dei container. Qualys descrive un caso in cui il caricamento di un profilo “userns” per /usr/bin/time permette a un utente non privilegiato di creare user namespace con capacità complete, aggirando le restrizioni di Ubuntu anche dove erano già stati corretti bypass pubblicamente noti. Questo è importante perché i namespace rappresentano una barriera critica negli ambienti containerizzati: se AppArmor, che dovrebbe rafforzare quella barriera, viene manipolato, il rischio non è solo la LPE sul nodo ma anche il collasso dell’isolamento tra workload.
Quali versioni sono colpite davvero
Sul piano delle versioni, Qualys è molto netta: tutti i kernel Linux dalla versione 4.11 in poi sono vulnerabili su qualunque distribuzione che integri AppArmor, incluse Ubuntu, Debian, SUSE e le rispettive derivate. Il vendor invita esplicitamente a fare riferimento agli advisory delle singole distribuzioni per la mappatura completa dei pacchetti e dei kernel vulnerabili, perché la situazione varia per release e backport. (Qualys)
Canonical aggiunge un dettaglio importante: tutte le release Ubuntu supportate sono colpite dalla vulnerabilità fondamentale di tipo confused deputy, ma la combinazione di falle che abilita gli scenari di local privilege escalation completi e di container escape non è presente in Trusty Tahr 14.04 LTS né in Xenial Xerus 16.04 LTS. Questo non significa che quelle release siano immuni, ma che non espongono l’intera catena offensiva descritta da Qualys. Le dimostrazioni pratiche di Qualys, invece, sono state realizzate almeno su Ubuntu 24.04.3 e Debian 13.1, cioè su piattaforme moderne e realistiche per ambienti enterprise.
Cosa è già patchato e cosa no
Sul piano della remediation, la situazione va letta con precisione. Le nove vulnerabilità kernel di CrackArmor hanno una correzione a livello di codice, come dimostra la serie di patch citata da Qualys, e Canonical afferma esplicitamente che gli aggiornamenti del kernel correggono tutte le vulnerabilità AppArmor identificate da Qualys. Questo è il punto centrale: per chiudere davvero la superficie di attacco, la correzione decisiva è quella del kernel.
Detto questo, la distribuzione degli aggiornamenti non è uniforme né istantanea su tutte le release e tutte le distribuzioni. Canonical scrive che, per Ubuntu, gli aggiornamenti del kernel “sono in fase di distribuzione” o “vengono resi disponibili” per le release supportate, e che la knowledge base verrà aggiornata man mano che nuovi kernel fix saranno pubblicati. Quindi, al momento della pubblicazione degli advisory, non è corretto dire che ogni singolo sistema Ubuntu fosse già materialmente aggiornabile nello stesso istante: è più corretto dire che la patch esiste ed è in rollout vendor.
Sul fronte userspace, invece, Canonical è più precisa. Gli aggiornamenti per sudo e util-linux sono già disponibili come mitigazioni per tutte le release Ubuntu supportate. La stessa Canonical pubblica le versioni corrette, ad esempio Noble 24.04 LTS con sudo 1.9.15p5-3ubuntu5.24.04.2 e util-linux 2.39.3-9ubuntu6.5, e Questing Quokka 25.10 con sudo 1.9.17p2-1ubuntu1.1 e util-linux 2.41-4ubuntu4.2. Canonical precisa però che questi aggiornamenti non sostituiscono il fix del kernel, ma agiscono come mitigazioni complementari.
Ci sono anche casi non colpiti sul piano userspace. Canonical segnala che sudo-rs non è affetto, e che alcune release non sono coinvolte da specifici tasselli della catena, come certe versioni di sudo o util-linux. Tuttavia, questo non cambia la raccomandazione operativa principale: installare sia le mitigazioni userspace sia gli aggiornamenti kernel.
- AppArmor, container-escape, CrackArmor, Debian AppArmor, Linux privilege escalation, local privilege escalation, Qualys CrackArmor, root Linux, securityinfo, SUSE AppArmor, Ubuntu AppArmor, vulnerabilità Linux
Articoli correlati
Altro in questa categoria
https://www.securityinfo.it/2026/03/16/crackarmor-nove-falle-in-apparmor-aprono-la-strada-al-root-di-linux/?utm_source=rss&utm_medium=rss&utm_campaign=crackarmor-nove-falle-in-apparmor-aprono-la-strada-al-root-di-linux
Questa velocità è coerente con un pattern ormai ricorrente nell’e-commerce: quando un bug consente una catena semplice e automatizzabile, gli attori malevoli trasformano la scansione in infezione in poche ore, soprattutto su piattaforme diffuse e con installazioni eterogenee come Magento. Sansec, inoltre, ha pubblicato una lista di indirizzi IP utilizzati per lo scanning mirato degli shop, segnale che la fase di ricognizione e selezione delle vittime è già industrializzata.
