La empresa Qualys ha identificado la tercera vulnerabilidad crítica de este año (CVE-2022-3328) en la utilidad snap-confine, que se entrega con el flag SUID root y es invocada por el proceso snapd para generar un entorno de ejecución para aplicaciones distribuidas en paquetes autónomos en formato snap. La vulnerabilidad permite a un usuario no privilegiado local ejecutar código con privilegios de root en la configuración predeterminada de Ubuntu. El problema ha sido solucionado en la versión snapd 2.57.6. Se han lanzado actualizaciones de paquetes para todas las ramas soportadas de Ubuntu.
Curiosamente, la vulnerabilidad discutida fue introducida durante la corrección de una vulnerabilidad similar en febrero en snap-confine. Los investigadores lograron preparar un exploit funcional que otorga acceso root en Ubuntu Server 22.04, donde además de la vulnerabilidad en snap-confine también están involucradas dos vulnerabilidades en el proceso multipathd (CVE-2022-41974, CVE-2022-41973), relacionadas con el eludimiento de la verificación de privilegios al enviar comandos privilegiados y el manejo inseguro de enlaces simbólicos.
La vulnerabilidad en snap-confine se debe a una condición de carrera en la función must_mkdir_and_open_with_perms(), añadida para protegerse contra la sustitución del directorio /tmp/snap.$SNAP_NAME por un enlace simbólico en el momento posterior a la verificación del propietario, pero antes de hacer la llamada al sistema mount para montar con bind los directorios para el paquete en formato snap. La protección añadida consistía en renombrar el directorio /tmp/snap.$SNAP_NAME a otro directorio en /tmp con un nombre aleatorio, si existía y no pertenecía al usuario root.
Durante la explotación de la operación de renombrado del directorio /tmp/snap.$SNAP_NAME, los investigadores se aprovecharon de que snap-confine también crea el directorio /tmp/snap.rootfs_XXXXXX para la raíz del contenido del paquete snap. La parte «XXXXXX» en el nombre se elige al azar mediante mkdtemp(), pero un paquete con el nombre «rootfs_XXXXXX» puede pasar la verificación en la función sc_instance_name_validate (es decir, la idea es que el nombre $SNAP_NAME tome el valor «rootfs_XXXXXX» y entonces la operación de renombrado sobrescribirá el directorio /tmp/snap.rootfs_XXXXXX con la raíz snap).
Para lograr el uso simultáneo de /tmp/snap.rootfs_XXXXXX y el renombrado de /tmp/snap.$SNAP_NAME, se ejecutaron dos instancias de snap-confine. Tan pronto como la primera instancia creaba /tmp/snap.rootfs_XXXXXX, el proceso se bloqueaba y se iniciaba la segunda instancia con el nombre de paquete rootfs_XXXXXX, lo que hacía que el directorio temporal /tmp/snap.$SNAP_NAME de la segunda instancia se convirtiera en el directorio raíz /tmp/snap.rootfs_XXXXXX de la primera. Justo después de realizar el renombramiento, la segunda instancia finalizaba de manera anómala, y /tmp/snap.rootfs_XXXXXX se reemplazaba con una manipulación de condición de carrera, como en la explotación de la vulnerabilidad de febrero. Después de la sustitución, se liberaba el bloqueo de ejecución de la primera instancia y los atacantes obtenían control total sobre el directorio raíz del snap.
En la última etapa, se creaba un enlace simbólico /tmp/snap.rootfs_XXXXXX/tmp, que era utilizado por la función sc_bootstrap_mount_namespace() para montar por enlace el directorio real /tmp disponible para escritura en cualquier directorio del sistema de archivos, ya que la llamada a mount() sigue a los enlaces simbólicos antes de realizar el montaje. Este tipo de montaje está bloqueado por las restricciones de AppArmor, pero para eludir este bloqueo, se aprovecharon dos vulnerabilidades auxiliares en multipathd en el exploit.
Fuente: opennet.ru
