Una race condition nascosta nel cuore del sandboxing di SnapIl 21 luglio 2026 il Threat Research Unit di Qualys ha reso pubblica CVE-2026-8933, una vulnerabilità di local privilege escalation (LPE) che colpisce snap-confine, il componente che costruisce l’ambiente sandbox per le applicazioni Snap su Ubuntu. Il difetto, classificato come “High” severity, permette a un utente locale non privilegiato di ottenere accesso root completo sulle installazioni di default di Ubuntu Desktop 24.04, 25.10 e 26.04.
La cosa interessante, dal punto di vista di chi amministra sistemi Linux, non è tanto la gravità in sé (le LPE locali sono un classico), quanto come ci si è arrivati: una modifica pensata per aumentare la sicurezza ha introdotto, per effetto collaterale, una finestra di race condition sfruttabile.
Perché snap-confine è cambiatosnap-confine è il binario che Canonical usa per costruire l’ambiente isolato in cui gira ogni applicazione Snap: monta i namespace, applica i profili AppArmor/seccomp e prepara le directory temporanee di lavoro. Storicamente era un binario set-uid-root: partiva già con i privilegi di root e li abbandonava progressivamente.
Per ridurre la superficie d’attacco, Canonical ha migrato snap-confine a un modello basato su set-capabilities: il processo ora gira con l’UID effettivo dell’utente chiamante, ma mantiene comunque delle capability quasi-root (tra cui CAP_SYS_ADMIN e simili) necessarie per completare il setup del sandbox. È un cambiamento in linea con il principio del least privilege, ma ha spostato il problema: durante l’inizializzazione, le directory temporanee sotto /tmp vengono create con proprietario l’utente non privilegiato, e solo in un secondo momento la ownership passa a root. In quella finestra, per quanto stretta, l’attaccante ha ancora pieno controllo sui file.
La catena di exploitIl team Qualys ha ricostruito un attacco che combina due race condition concorrenti:
Bypass del mount namespace via FUSE: l’attaccante monta un filesystem FUSE sopra la directory temporanea di scratch appena creata, prima che snap-confine applichi l’isolamento tramite mount namespace. In questo modo la directory resta accessibile anche dall’esterno del sandbox.
Symlink race su fchown(): l’attaccante sostituisce un file atteso con un symlink verso un target arbitrario. Quando snap-confine tenta di creare un file nel sandbox, la open() segue il symlink e scrive sul target reale. Una seconda race condition permette poi di allargare i permessi a 0666 prima che venga invocata fchown() per trasferire la ownership a root.
Escalation via udev: per aggirare la confinazione AppArmor, l’exploit punta al percorso /run/udev/, che consente accesso in lettura/scrittura. Depositando un file .rules malevolo in /run/udev/rules.d/ e innescando un ciclo di mount/unmount FUSE, l’attaccante costringe il demone systemd-udevd a eseguire comandi arbitrari come root.
Il risultato finale: da semplice accesso locale non privilegiato a controllo completo del sistema, senza bisogno di interazione da parte di altri utenti.
Versioni coinvolte e patch disponibiliSono interessate le release che spediscono di default la variante set-capabilities di snap-confine:
Ubuntu Desktop 26.04
Ubuntu Desktop 25.10
Ubuntu Desktop 24.04 (con pacchetti snapd aggiornati)
Canonical ha rilasciato pacchetti snapd corretti, tra cui 2.76+ubuntu26.04.3 per Ubuntu 26.04, 2.76+ubuntu24.04.1 per Ubuntu 24.04 e 2.76+ubuntu22.04.1 per Ubuntu 22.04. La disclosure è stata coordinata con l’Ubuntu Security Team.
Come verificare se un sistema è vulnerabilePer controllare la versione di snapd installata:
snap version
apt-cache policy snapdSe la versione del pacchetto snapd è precedente a quelle corrette indicate sopra, il sistema va aggiornato immediatamente:
sudo apt update
sudo apt install --only-upgrade snapd
snap versionPer un controllo su larga scala, chi usa strumenti di vulnerability management (Qualys CSAM o equivalenti) può cercare asset con sistema operativo Ubuntu e pacchetto snapd installato, incrociando poi la versione con quella patchata.
Mitigazioni in attesa della patchSe non è possibile applicare l’aggiornamento immediatamente, alcune contromisure temporanee riducono l’esposizione:
Limitare l’accesso a shell locale ai soli utenti fidati, specialmente su workstation condivise o ambienti multi-utente (lab, terminal server, VDI).
Monitorare la creazione di regole udev non autorizzate sotto /run/udev/rules.d/, ad esempio con auditd:
auditctl -w /run/udev/rules.d/ -p wa -k udev_rules_watch
Disabilitare il montaggio FUSE per utenti non privilegiati dove non strettamente necessario, tramite policy su /etc/fuse.conf o restrizioni AppArmor aggiuntive.
Nessuna di queste misure sostituisce la patch ufficiale: sono palliativi utili solo per il tempo strettamente necessario a pianificare l’aggiornamento.
ConclusioneCVE-2026-8933 è un promemoria utile per chi progetta meccanismi di sandboxing e privilege dropping: il passaggio da set-uid a set-capabilities è, sulla carta, una scelta più sicura, ma introduce una superficie temporale (la finestra tra creazione del file e trasferimento della ownership) che va gestita con la stessa attenzione riservata alle race condition classiche nei binari set-uid. Per chi amministra flotte Ubuntu Desktop, la priorità pratica resta semplice: verificare le versioni di snapd installate, applicare la patch e, nel frattempo, restringere l’accesso shell locale dove possibile.
Fonte: Qualys Threat Research Unit – CVE-2026-8933: Local Privilege Escalation in Set-Capabilities snap-confine
