Qualys ha identificato quest'anno una terza grave vulnerabilità (CVE-2022-3328) nell'utility snap-confine, che viene fornita con il flag SUID root e viene richiamata dal processo snapd per formare un ambiente eseguibile per le applicazioni distribuite in pacchetti autonomi. nel formato snap. La vulnerabilità consente a un utente locale non privilegiato di eseguire il codice come root nella configurazione predefinita di Ubuntu. Il problema è stato risolto nella versione di snapd 2.57.6. Sono stati rilasciati aggiornamenti dei pacchetti per tutti i rami supportati di Ubuntu.
È interessante notare che la vulnerabilità in questione è stata introdotta nel processo di correzione di una vulnerabilità simile di febbraio in snap-confine. I ricercatori sono stati in grado di preparare un exploit funzionante che fornisce l'accesso root in Ubuntu Server 22.04, che, oltre alla vulnerabilità snap-confine, coinvolge anche due vulnerabilità nel processo multipathd (CVE-2022-41974, CVE-2022-41973) relativo all'elusione del controllo delle autorizzazioni durante il passaggio di comandi privilegiati e alla gestione non sicura dei collegamenti simbolici.
La vulnerabilità in snap-confine è causata da una race condition nella funzione must_mkdir_and_open_with_perms(), aggiunta per proteggere dalla sostituzione della directory /tmp/snap.$SNAP_NAME con un collegamento simbolico dopo il controllo del proprietario, ma prima della chiamata di sistema mount viene chiamato per eseguire il bind-mount delle directory al suo interno per un pacchetto in formato snap. La sicurezza aggiunta consisteva nel rinominare la directory /tmp/snap.$SNAP_NAME in un'altra directory in /tmp con un nome casuale se esiste e non è di proprietà dell'utente root.
Sfruttando l'operazione di ridenominazione della directory /tmp/snap.$SNAP_NAME, i ricercatori hanno approfittato del fatto che snap-confine crea anche una directory /tmp/snap.rootfs_XXXXXX per la root dei contenuti del pacchetto snap. La parte "XXXXXX" del nome viene scelta casualmente da mkdtemp(), ma un pacchetto denominato "rootfs_XXXXXX" può passare sc_instance_name_validate (ovvero l'idea è di avere $SNAP_NAME impostato su "rootfs_XXXXXX" e quindi l'operazione di ridenominazione comporterà la sovrascrittura la directory /tmp/snap.rootfs_XXXXXX con lo snap root).
Per ottenere l'utilizzo simultaneo di /tmp/snap.rootfs_XXXXXX e la ridenominazione di /tmp/snap.$SNAP_NAME, sono state avviate due istanze di snap-confine. Non appena la prima istanza creava /tmp/snap.rootfs_XXXXXX, il processo si bloccava e veniva avviata una seconda istanza con il nome del pacchetto rootfs_XXXXXX, facendo sì che la directory temporanea della seconda istanza /tmp/snap.$SNAP_NAME diventasse /tmp/snap .rootfs_XXXXXX directory root della prima istanza. Immediatamente dopo l'esecuzione della ridenominazione, la seconda istanza si è bloccata e /tmp/snap.rootfs_XXXXXX è stato sostituito con la manipolazione delle condizioni di competizione, come nello sfruttamento della vulnerabilità di febbraio. Dopo la modifica, il blocco dell'esecuzione è stato rimosso inizialmente e gli aggressori hanno ottenuto il pieno controllo sulla directory root dello snap.
L'ultimo passaggio è stato quello di creare un collegamento simbolico /tmp/snap.rootfs_XXXXXX/tmp che è stato utilizzato dalla funzione sc_bootstrap_mount_namespace() per eseguire il bind-mount della directory reale scrivibile /tmp su qualsiasi directory nel file system, poiché segue la chiamata mount() collegamenti simbolici prima del montaggio. Tale montaggio è bloccato dalle restrizioni di AppArmor, ma per aggirare questo blocco, l'exploit ha sfruttato due vulnerabilità ausiliarie in multipathd.
Fonte: opennet.ru