La société Qualys a découvert une troisième vulnérabilité critique cette année (CVE-2022-3328) dans l'outil snap-confine, distribué avec le drapeau SUID root et appelé par le processus snapd pour créer un environnement d'exécution pour les applications distribuées dans des paquets autonomes au format snap. Cette vulnérabilité permet à un utilisateur local non privilégié d'exécuter du code avec des droits root dans une configuration Ubuntu par défaut. Le problème a été résolu dans la version snapd 2.57.6. Des mises à jour de paquets ont été publiées pour toutes les branches d'Ubuntu prises en charge.
Il est intéressant de noter que la vulnérabilité en question a été introduite lors de la correction d'une vulnérabilité similaire en février dans snap-confine. Les chercheurs ont réussi à préparer un exploit fonctionnel offrant un accès root dans Ubuntu Server 22.04, où, en plus de la vulnérabilité dans snap-confine, deux autres vulnérabilités dans le processus multipathd (CVE-2022-41974, CVE-2022-41973) sont également impliquées, liées à un contournement des vérifications d'autorisation lors de l'exécution de commandes privilégiées et à une manipulation non sécurisée des liens symboliques.
La vulnérabilité dans snap-confine est due à une condition de course dans la fonction must_mkdir_and_open_with_perms(), ajoutée pour protéger contre la substitution du répertoire /tmp/snap.$SNAP_NAME par un lien symbolique après la vérification du propriétaire, mais avant l'appel système mount pour monter des répertoires du paquet au format snap. La protection ajoutée consistait à renommer le répertoire /tmp/snap.$SNAP_NAME en un autre répertoire dans /tmp avec un nom aléatoire, s'il existe et n'appartient pas à l'utilisateur root.
Lors de l'exploitation de l'opération de renommage du répertoire /tmp/snap.$SNAP_NAME, les chercheurs ont exploité le fait que snap-confine crée également un répertoire /tmp/snap.rootfs_XXXXXX pour le contenu racine du paquet snap. La partie «XXXXXX» du nom est choisie aléatoirement à l'aide de mkdtemp(), mais le paquet nommé «rootfs_XXXXXX» peut passer la vérification dans la fonction sc_instance_name_validate (c'est-à-dire que l'idée est que le nom $SNAP_NAME prenne la valeur «rootfs_XXXXXX», ce qui entraînera le renommage du répertoire /tmp/snap.rootfs_XXXXXX avec la racine snap).
Pour permettre l'utilisation simultanée de /tmp/snap.rootfs_XXXXXX et de renommer /tmp/snap.$SNAP_NAME, deux instances de snap-confine ont été lancées. Dès que la première instance créait /tmp/snap.rootfs_XXXXXX, le processus se bloquait et la deuxième instance, portant le nom du paquet rootfs_XXXXXX, était lancée, ce qui entraînait le fait que le répertoire temporaire /tmp/snap.$SNAP_NAME de la seconde instance devenait le répertoire racine /tmp/snap.rootfs_XXXXXX de la première. Juste après l'exécution du renommage, la seconde instance se terminait de manière inattendue, et /tmp/snap.rootfs_XXXXXX était remplacé par une manipulation d'état de concurrence, comme lors de l'exploitation de la vulnérabilité de février. Après ce remplacement, le verrouillage d'exécution de la première instance était levé et les attaquants obtenaient un contrôle total sur le répertoire racine du snap.
À la dernière étape, un lien symbolique /tmp/snap.rootfs_XXXXXX/tmp était créé, qui était utilisé par la fonction sc_bootstrap_mount_namespace() pour monter en liaison le répertoire réel /tmp, accessible en écriture, dans n'importe quel répertoire du système de fichiers, car l'appel à mount() suit les liens symboliques avant le montage. Ce type de montage est bloqué par les restrictions AppArmor, mais pour contourner cette protection, l'exploit utilisait deux vulnérabilités auxiliaires dans multipathd.
Source : opennet.ru
