Qualys a identifié cette année la troisième vulnérabilité dangereuse (CVE-2022-3328) dans l'utilitaire snap-confine, fourni avec l'indicateur racine SUID et appelé par le processus snapd pour créer un environnement exécutable pour les applications distribuées dans des packages autonomes. au format instantané. La vulnérabilité permet à un utilisateur local non privilégié d'exécuter du code en tant que root dans la configuration Ubuntu par défaut. Le problème est résolu dans la version Snapd 2.57.6. Des mises à jour de packages ont été publiées pour toutes les branches prises en charge d'Ubuntu.
Il est intéressant de noter que la vulnérabilité en question a été introduite lors du processus de correction d'une vulnérabilité similaire de février dans snap-confine. Les chercheurs ont pu préparer un exploit fonctionnel qui fournit un accès root à Ubuntu Server 22.04, qui, en plus de la vulnérabilité dans snap-confine, implique également deux vulnérabilités dans le processus multipathd (CVE-2022-41974, CVE-2022-41973). , associé au contournement du contrôle d'autorité lors de la transmission de commandes privilégiées et au travail dangereux avec des liens symboliques.
La vulnérabilité dans snap-confine est causée par une condition de concurrence critique dans la fonction must_mkdir_and_open_with_perms(), ajoutée pour se protéger contre la substitution du répertoire /tmp/snap.$SNAP_NAME par un lien symbolique après avoir vérifié le propriétaire, mais avant d'appeler le système de montage. appelez-y pour lier des répertoires de montage pour un package au format instantané. La protection supplémentaire 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 à root.
En exploitant l'opération de renommage du répertoire /tmp/snap.$SNAP_NAME, les chercheurs ont profité du fait que snap-confine crée également un répertoire /tmp/snap.rootfs_XXXXXX pour la racine du contenu du package snap. La partie "XXXXXX" du nom est choisie aléatoirement par mkdtemp(), mais un package nommé "rootfs_XXXXXX" peut être validé dans la fonction sc_instance_name_validate (c'est-à-dire que l'idée est que $SNAP_NAME sera défini sur "rootfs_XXXXXX" puis l'opération de renommage entraînera l'écrasement du répertoire /tmp/snap.rootfs_XXXXXX par le snap racine).
Afin de 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. Une fois la première instance créée /tmp/snap.rootfs_XXXXXX, le processus se bloquerait et une deuxième instance démarrerait avec le nom de package rootfs_XXXXXX, faisant du répertoire temporaire de la deuxième instance /tmp/snap.$SNAP_NAME le répertoire racine /tmp/snap. .rootfs_XXXXXX du premier. Immédiatement après le changement de nom, la deuxième instance s'est écrasée et /tmp/snap.rootfs_XXXXXX a été remplacé par une manipulation de condition de concurrence critique, comme lors de l'exploitation de la vulnérabilité de février. Après la substitution, le verrou d'exécution a été supprimé de la première instance et les attaquants ont pris le contrôle total du répertoire racine du snap.
La dernière étape consistait à créer un lien symbolique /tmp/snap.rootfs_XXXXXX/tmp, qui était utilisé par la fonction sc_bootstrap_mount_namespace() pour lier le répertoire réel /tmp inscriptible à n'importe quel répertoire du système de fichiers, depuis l'appel mount() suit les liens symboliques avant le montage. Un tel montage est bloqué par les restrictions d'AppArmor, mais pour contourner ce blocage, l'exploit a utilisé deux vulnérabilités auxiliaires dans multipathd.
Source: opennet.ru