L'azienda Qualys ha identificato una terza vulnerabilità critica quest'anno (CVE-2022-3328) nell'utility snap-confine, fornita con il flag SUID root e invocata dal processo snapd per creare un ambiente di esecuzione per le applicazioni distribuite in pacchetti autonomi nel formato snap. La vulnerabilità consente a un utente non privilegiato locale di eseguire codice con i diritti di root nella configurazione predefinita di Ubuntu. Il problema è stato risolto con il rilascio 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 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, dove oltre alla vulnerabilità in snap-confine sono state coinvolte anche due vulnerabilità nel processo multipathd (CVE-2022-41974, CVE-2022-41973), legate all'aggiramento del controllo delle autorizzazioni durante la trasmissione di comandi privilegiati e a una gestione insicura dei collegamenti simbolici.
La vulnerabilità in snap-confine è dovuta a una condizione di competizione nella funzione must_mkdir_and_open_with_perms(), aggiunta per prevenire la sostituzione della directory /tmp/snap.$SNAP_NAME con un collegamento simbolico nel momento successivo al controllo del proprietario, ma prima della chiamata al sistema per il montaggio bind. 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.
Nell'exploit dell'operazione di rinominazione della directory /tmp/snap.$SNAP_NAME, i ricercatori hanno sfruttato il fatto che snap-confine crea anche la directory /tmp/snap.rootfs_XXXXXX per la radice del contenuto del pacchetto snap. La parte «XXXXXX» nel nome è scelta casualmente utilizzando mkdtemp(), ma un pacchetto con il 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 porterebbe a sovrascrivere la directory /tmp/snap.rootfs_XXXXXX con la radice snap).
Per ottenere un utilizzo simultaneo di /tmp/snap.rootfs_XXXXXX e il rinominamento di /tmp/snap.$SNAP_NAME, sono stati avviati due esempi di snap-confine. Non appena il primo esempio creava /tmp/snap.rootfs_XXXXXX, il processo veniva bloccato e si avviava il secondo esempio con il nome del pacchetto rootfs_XXXXXX, il che portava al fatto che la directory temporanea /tmp/snap.$SNAP_NAME del secondo esempio diventava la directory radice /tmp/snap.rootfs_XXXXXX del primo. Subito dopo l'esecuzione del rinominamento, il secondo esempio terminava in modo anomalo e /tmp/snap.rootfs_XXXXXX veniva sostituito mediante la manipolazione della condizione di gara, come nell'exploit della vulnerabilità di febbraio. Dopo la sostituzione, veniva rimossa la blocco di esecuzione del primo esempio e gli attaccanti ottenevano il pieno controllo sulla directory radice snap.
Nella fase finale, veniva creata un collegamento simbolico /tmp/snap.rootfs_XXXXXX/tmp, che veniva utilizzato dalla funzione sc_bootstrap_mount_namespace() per il montaggio bind della directory effettivamente scrivibile /tmp in qualsiasi directory FS, poiché la chiamata mount() segue i collegamenti simbolici prima del montaggio. Tale montaggio è bloccato dai vincoli di AppArmor, ma per aggirare questo blocco nell'exploit sono state utilizzate due vulnerabilità ausiliarie in multipathd.
Fonte: opennet.ru
