L'azienda Qualys ha identificato la terza vulnerabilità critica di quest'anno (CVE-2022-3328) nell'utility snap-confine, fornita con il flag SUID root e chiamata dal processo snapd per creare un ambiente di esecuzione per le applicazioni distribuite in pacchetti autonomi nel formato snap. Questa vulnerabilità consente a un utente locale non privilegiato di eseguire codice con diritti di root nella configurazione predefinita di Ubuntu. Il problema è stato risolto nella versione snapd 2.57.6. Sono stati rilasciati aggiornamenti per tutti i rami supportati di Ubuntu.
È interessante notare che la vulnerabilità in questione è stata introdotta durante la correzione di una vulnerabilità simile riscontrata a febbraio in snap-confine. I ricercatori sono riusciti a preparare un exploit funzionante che fornisce accesso root su Ubuntu Server 22.04, in cui oltre alla vulnerabilità in snap-confine sono coinvolte anche due vulnerabilità nel processo multipathd (CVE-2022-41974, CVE-2022-41973), relative all'aggiramento della verifica delle autorizzazioni durante l'invio di comandi privilegiati e alla gestione non sicura dei collegamenti simbolici.
La vulnerabilità in snap-confine è causata da una condizione di race nella funzione must_mkdir_and_open_with_perms(), aggiunta per proteggere dalla sostituzione della directory /tmp/snap.$SNAP_NAME con un collegamento simbolico dopo la verifica del proprietario, ma prima della chiamata di sistema mount per il bind-mount delle directory del pacchetto nel formato snap. La protezione aggiunta consisteva nel rinominare la directory /tmp/snap.$SNAP_NAME in un'altra directory in /tmp con un nome casuale, se esiste e non appartiene all'utente root.
Durante l'operazione di rinominazione della cartella /tmp/snap.$SNAP_NAME, i ricercatori hanno sfruttato il fatto che snap-confine crea anche la cartella /tmp/snap.rootfs_XXXXXX per il contenuto del pacchetto snap. La parte "XXXXXX" nel nome è scelta casualmente tramite mkdtemp(), ma un pacchetto con nome "rootfs_XXXXXX" può superare il controllo nella funzione sc_instance_name_validate (cioè, l'idea è che il nome $SNAP_NAME prenda il valore "rootfs_XXXXXX" e quindi l'operazione di rinominazione porterà alla sovrascrittura della cartella /tmp/snap.rootfs_XXXXXX con la radice snap).
Per ottenere l'utilizzo simultaneo di /tmp/snap.rootfs_XXXXXX e la rinomina di /tmp/snap.$SNAP_NAME, sono stati avviati due istanze di snap-confine. Non appena la prima istanza creava /tmp/snap.rootfs_XXXXXX, il processo si bloccava e veniva avviata la seconda istanza con il nome del pacchetto rootfs_XXXXXX, il che portava a far sì che la cartella temporanea /tmp/snap.$SNAP_NAME della seconda istanza diventasse la cartella radice /tmp/snap.rootfs_XXXXXX della prima. Subito dopo l'esecuzione della rinominazione, la seconda istanza terminava in modo anomalo e /tmp/snap.rootfs_XXXXXX veniva sostituito con una manipolazione della condizione di competizione, come nella sfruttazione della vulnerabilità di febbraio. Dopo la sostituzione, veniva rimossa la restrizione di esecuzione della prima istanza e gli aggressori ottenevano il pieno controllo sulla cartella radice dello snap.
Nell'ultima fase veniva creata un collegamento simbolico /tmp/snap.rootfs_XXXXXX/tmp, che veniva utilizzato dalla funzione sc_bootstrap_mount_namespace() per il bind-mounting della cartella reale scrivibile /tmp in qualsiasi cartella del FS, poiché la chiamata a mount() segue i collegamenti simbolici prima del montaggio. Tale montaggio è bloccato dalle restrizioni di AppArmor, ma per eludere questo blocco l'exploit ha utilizzato due vulnerabilità ausiliarie in multipathd.
Fonte: opennet.ru
