La empresa Qualys ha identificado la tercera vulnerabilidad cr\u00edtica de este a\u00f1o (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\u00f3n para aplicaciones distribuidas en paquetes aut\u00f3nomos en formato snap. La vulnerabilidad permite a un usuario no privilegiado local ejecutar c\u00f3digo con privilegios de root en la configuraci\u00f3n predeterminada de Ubuntu. El problema ha sido solucionado en la versi\u00f3n snapd 2.57.6. Se han lanzado actualizaciones de paquetes para todas las ramas soportadas de Ubuntu. <\/p>\n
Curiosamente, la vulnerabilidad discutida fue introducida durante la correcci\u00f3n 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\u00e1s de la vulnerabilidad en snap-confine tambi\u00e9n est\u00e1n involucradas dos vulnerabilidades en el proceso multipathd (CVE-2022-41974, CVE-2022-41973), relacionadas con el eludimiento de la verificaci\u00f3n de privilegios al enviar comandos privilegiados y el manejo inseguro de enlaces simb\u00f3licos. <\/p>\n
La vulnerabilidad en snap-confine se debe a una condici\u00f3n de carrera en la funci\u00f3n must_mkdir_and_open_with_perms(), a\u00f1adida para protegerse contra la sustituci\u00f3n del directorio \/tmp\/snap.$SNAP_NAME por un enlace simb\u00f3lico en el momento posterior a la verificaci\u00f3n 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\u00f3n a\u00f1adida consist\u00eda en renombrar el directorio \/tmp\/snap.$SNAP_NAME a otro directorio en \/tmp con un nombre aleatorio, si exist\u00eda y no pertenec\u00eda al usuario root. <\/p>\n
Durante la operaci\u00f3n de renombrar el directorio \/tmp\/snap.$SNAP_NAME, los investigadores aprovecharon que snap-confine tambi\u00e9n crea el directorio \/tmp\/snap.rootfs_XXXXXX para el contenido ra\u00edz 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\u00f3n en la funci\u00f3n sc_instance_name_validate (es decir, la idea es que el nombre $SNAP_NAME tome el valor «rootfs_XXXXXX» y entonces la operaci\u00f3n de renombrar llevar\u00e1 a sobrescribir el directorio \/tmp\/snap.rootfs_XXXXXX con la ra\u00edz snap). <\/p>\n
Para lograr el uso simult\u00e1neo 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\u00eda que el directorio temporal \/tmp\/snap.$SNAP_NAME de la segunda instancia se convirtiera en el directorio ra\u00edz \/tmp\/snap.rootfs_XXXXXX de la primera. Justo despu\u00e9s de realizar el renombramiento, la segunda instancia finalizaba de manera an\u00f3mala, y \/tmp\/snap.rootfs_XXXXXX se reemplazaba con una manipulaci\u00f3n de condici\u00f3n de carrera, como en la explotaci\u00f3n de la vulnerabilidad de febrero. Despu\u00e9s de la sustituci\u00f3n, se liberaba el bloqueo de ejecuci\u00f3n de la primera instancia y los atacantes obten\u00edan control total sobre el directorio ra\u00edz del snap. <\/p>\n