Una race condition nascosta nel cuore del sandboxing di Snap

Il 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 è cambiato

snap-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 exploit

Il 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 disponibili

Sono 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 è vulnerabile

Per controllare la versione di snapd installata:

snap version
apt-cache policy snapd

Se 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 version

Per 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 patch

Se 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.

Conclusione

CVE-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