26 marzo 2026 · 8 min lettura
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Self-HostingLa cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Self-HostingIscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
900k siti WordPress esposti a RCE critico, 500k a file read su wp-config.php. Se ospiti WordPress in homelab o su VPS, ecco cosa fare nei prossimi 30 minuti.
Erano le tre di notte quando ho sentito il mio telefono vibrare sul comodino. Un alert di Proxmox: CPU al 100% su un container che doveva stare fermo. Ho aperto il terminale dal letto, gli occhi ancora mezzi chiusi, e quello che ho trovato nei log mi ha svegliato di colpo. Qualcuno — o qualcosa — stava tentando di scrivere in /sys/kernel/security/apparmor/.load. Da un container non privilegiato.
Non era un attacco mirato al mio homelab, ovviamente. Era uno script automatizzato che girava su porte esposte. Ma il punto è un altro: quel tentativo avrebbe potuto funzionare. Perché la vulnerabilità CrackArmor in AppArmor su Linux — quella che Qualys TRU ha divulgato il 12 marzo 2026 — era lì da nove anni, silenziosa, in attesa.
Nove vulnerabilità. Presenti dal kernel v4.11, anno 2017. Dodici milioni e seicentomila istanze enterprise esposte — Ubuntu, Debian, SUSE. Il nome collettivo è CrackArmor, e se gestisci un homelab con Proxmox o Docker su Ubuntu, ti riguarda direttamente. Chi ha seguito la vicenda della supply chain di Trivy sa che i guardiani della sicurezza possono diventare il problema. Stavolta il guardiano è AppArmor stesso.
Due CVE pubblicati il 18 marzo: CVE-2026-23268 e CVE-2026-23269. Ma il numero non rende l’idea. Serve capire il meccanismo.
Il cuore di CrackArmor è un pattern classico nella sicurezza informatica: il confused deputy. Un componente privilegiato che viene ingannato per compiere azioni che non dovrebbe.
Funziona così. Nel filesystem virtuale del kernel, sotto /sys/kernel/security/apparmor/, esistono tre pseudo-file: .load, .replace, .remove. Servono per caricare, modificare e rimuovere profili di sicurezza. I permessi? Mode 0666 — leggibili e scrivibili da chiunque.
Il problema sta in un errore architetturale preciso.
Il controllo dei permessi avviene al momento della write(), non della open(). Un utente non privilegiato può aprire quei file senza problemi. Poi usa su -P come proxy privilegiato per scrivere dati arbitrari. Il kernel vede la scrittura arrivare da un processo con privilegi elevati e la accetta. Il confused deputy ha eseguito l’ordine.
«Qualsiasi controllo d’accesso su write() è un code smell nel modello UNIX tradizionale.» — Epa, sviluppatore kernel, commento su LWN.net
C’è di peggio. Una delle nove falle — un out-of-bounds read nella funzione aa_dfa_match() — permette di leggere fino a 64 KB di memoria kernel. Abbastanza per estrarre puntatori KASLR e rendere un exploit affidabile e ripetibile.
Secondo la Cloud Security Alliance, l’exploit raggiunge una root shell su Ubuntu 24.04 LTS in meno di 4,5 secondi. Quattro secondi e mezzo per passare da utente normale ad accesso completo al sistema.
Serve accesso locale e un utente con password. Non è un attacco remoto. Questa distinzione conta, e ci torneremo. Ma in un contesto dove container non fidati girano su host condivisi — Proxmox, Kubernetes, qualsiasi piattaforma multi-tenant — «accesso locale» è la condizione di partenza, non un ostacolo.
Qualys TRU ha scoperto le falle e contattato i maintainer il 10 luglio 2025. La divulgazione pubblica è arrivata il 12 marzo 2026. Otto mesi di lavoro dietro le quinte.
John Johansen, maintainer di AppArmor, ha categorizzato i nove bug in cinque gruppi di gravità e prodotto undici patch, tutte integrate upstream il giorno della divulgazione. Le patch per Ubuntu coprono le versioni 25.10, 24.04 LTS, 22.04 LTS e 20.04 LTS. Per chi è ancora su 18.04, 16.04 o 14.04: le patch sono in stato «pending».
Tradotto in versione kernel per Ubuntu 24.04: il fix è nel pacchetto 6.8.0-106.106. Anche sudo ha ricevuto un aggiornamento specifico: versione 1.9.15p5-3ubuntu5.24.04.2.
Una curiosità.
sudo-rs — la riscrittura in Rust di sudo, default su Ubuntu 25.10+ — non è vulnerabile. Non implementa le email notifications che l’exploit sfrutta come vettore. A volte riscrivere da zero paga.
CrackArmor non è un caso isolato. È l’ultimo capitolo di un pattern ricorrente nella sicurezza Linux.
Dirty COW, CVE-2016-5195: privilege escalation locale nel kernel, presente dal 2007, scoperta nel 2016 dopo nove anni. Stessa dinamica — una falla dormiente che aspetta il ricercatore giusto. Dirty Pipe nel 2022: altra escalation locale, e tra le mitigazioni suggerite c’era proprio AppArmor. L’ironia è pesante.
Ma l’ironia più grossa riguarda Qualys stessa. Nel 2022 il loro team scoprì vulnerabilità critiche in Snap. La mitigazione raccomandata? Rafforzare i profili AppArmor. Quattro anni dopo, sono loro a dimostrare che AppArmor era il buco.
Non tutti la pensano allo stesso modo, e le voci critiche meritano spazio.
Su LWN.net, la community kernel ha reagito con scetticismo misurato. L’exploit richiede accesso locale e un utente con password — non è un attacco remoto. Il nome «CrackArmor» e il numero «12,6 milioni» puzzano di marketing. La falla, tecnicamente, è un bug banale: check dei permessi nel punto sbagliato. Niente di sofisticato.
Hanno ragione? In parte sì.
Ma c’è un’altra lettura, più radicale. Edera.dev — startup che lavora su hypervisor leggeri — ha scritto qualcosa che va oltre il bug singolo: il problema non è la falla specifica, ma il fatto che meccanismi di enforcement di sicurezza residenti in un kernel condiviso possono essi stessi diventare superficie d’attacco. Non basta patchare. Serve ripensare l’architettura.
«CrackArmor dimostra che anche le protezioni più radicate possono essere aggirate senza credenziali di amministratore.» — Dilip Bachwani, CTO Qualys
Ecco il dettaglio che molti hanno trascurato. CrackArmor non arriva nel vuoto. Arriva in un momento in cui AppArmor stava già perdendo terreno.
Febbraio 2025: openSUSE annuncia lo switch a SELinux. Poco dopo, Microsoft rimuove il supporto AppArmor da Azure Linux 3.0 per AKS e raccomanda SELinux come MAC predefinito. Due colossi che cambiano direzione, prima che CrackArmor diventasse pubblico. Sapevano qualcosa? O semplicemente avevano già valutato i limiti strutturali di un sistema basato su path anziché su label, senza supporto MLS/MCS, incapace di separare container tra loro?
RHEL e Fedora, con SELinux di default, non sono colpiti. Amazon Linux nemmeno. Il 43,1% del mercato enterprise Linux era già al sicuro per scelta architetturale. Ubuntu, con il 33,9% e AppArmor abilitato sull’86% dei server, porta il peso maggiore.
Se hai un homelab Proxmox con container LXC, questa sezione è per te.
Proxmox VE usa un kernel Debian-based. Se non hai aggiornato dopo il 12 marzo, ogni container LXC sul tuo host è potenzialmente esposto a CrackArmor. Docker su Ubuntu applica profili AppArmor di default — stessa esposizione. E chi ha provato a far girare Docker dentro container LXC unprivileged su Proxmox 9 sa già che AppArmor creava problemi ancor prima di CrackArmor.
Il rischio concreto: container escape. Un’immagine Docker malevola, scaricata magari da un registry non verificato, potrebbe sfruttare la catena di vulnerabilità per uscire dal container e ottenere root sull’host. Senza bisogno di cooperazione da parte di processi privilegiati.
Le azioni immediate, in ordine di priorità:
# 1. Aggiorna tutto e riavvia
sudo apt update && sudo apt upgrade -y && sudo reboot
# 2. Dopo il riavvio, verifica kernel
uname -r
# Deve essere >= 6.8.0-106.106 su Ubuntu 24.04
# 3. Controlla stato AppArmor
sudo aa-status
# 4. Monitora eventi AVC con auditd
sudo apt install auditd -y
sudo auditctl -w /sys/kernel/security/apparmor/ -p wa -k apparmor_accessPer chi vuole andare oltre la patch: il sysctl kernel.unprivileged_userns_apparmor_policy mitiga gli attacchi via user namespace. Landlock, un LSM più recente, offre un modello di sandboxing che non soffre degli stessi limiti architetturali. C’è anche landrun, un tool CLI in Go con oltre 2100 stelle su GitHub, che semplifica l’uso di Landlock da riga di comando.
CrackArmor, la vulnerabilità in AppArmor su Linux, non è la fine del mondo. È un bug locale, richiede un utente con password, e le patch esistono già. Ma è la conferma di qualcosa che il settore stava già metabolizzando: AppArmor ha limiti strutturali che vanno oltre il singolo CVE. openSUSE e Microsoft se ne sono andati prima della disclosure. Il kernel condiviso come piano di enforcement è un modello che scricchiola. Per il tuo homelab la risposta immediata è semplice — aggiorna, riavvia, verifica. Per il lungo termine, tieni d’occhio SELinux, Landlock e le alternative che separano davvero il piano di sicurezza dal kernel. La guardia ha dormito nove anni. Svegliala tu.
Fonti: Qualys Blog, Ubuntu Security Advisory, Canonical Blog, CSO Online, Infosecurity Magazine, LWN.net, Edera.dev, The Stack, SecurityInfo.it, CSA Research Note