Vulnerabilidad raíz en el kit de herramientas de administración de paquetes Snap

Qualys ha identificado la tercera vulnerabilidad peligrosa de este año (CVE-2022-3328) en la utilidad snap-confine, que viene con el indicador raíz SUID y es invocada por el proceso snapd para crear un entorno ejecutable para aplicaciones distribuidas en paquetes independientes. en formato instantáneo. La vulnerabilidad permite a un usuario local sin privilegios lograr la ejecución de código como root en la configuración predeterminada de Ubuntu. El problema se solucionó en la versión snapd 2.57.6. Se han publicado actualizaciones de paquetes para todas las ramas compatibles de Ubuntu.

Curiosamente, la vulnerabilidad en cuestión se introdujo durante el proceso de reparación de una vulnerabilidad similar de febrero en snap-confine. Los investigadores pudieron preparar un exploit funcional que proporciona acceso root a Ubuntu Server 22.04, que, además de la vulnerabilidad en snap-confine, también involucra dos vulnerabilidades en el proceso multipathd (CVE-2022-41974, CVE-2022-41973) , asociado con eludir la verificación de autoridad al transmitir comandos privilegiados y trabajar inseguro con enlaces simbólicos.

La vulnerabilidad en snap-confine es causada por una condición de carrera en la función must_mkdir_and_open_with_perms(), agregada para proteger contra la sustitución del directorio /tmp/snap.$SNAP_NAME con un enlace simbólico después de verificar el propietario, pero antes de llamar al sistema de montaje. Llame para vincular directorios de montaje en él para obtener un paquete en formato instantáneo. La protección adicional fue cambiar el nombre del directorio /tmp/snap.$SNAP_NAME a otro directorio en /tmp con un nombre aleatorio si existe y no es propiedad de root.

Al explotar la operación de cambio de nombre del directorio /tmp/snap.$SNAP_NAME, los investigadores aprovecharon el hecho de que snap-confine también crea un directorio /tmp/snap.rootfs_XXXXXX para la raíz del contenido del paquete snap. mkdtemp() elige aleatoriamente la parte "XXXXXX" del nombre, pero un paquete llamado "rootfs_XXXXXX" se puede validar en la función sc_instance_name_validate (es decir, la idea es que $SNAP_NAME se establezca en "rootfs_XXXXXX" y luego se realice la operación de cambio de nombre resultará en sobrescribir el directorio /tmp/snap.rootfs_XXXXXX con el complemento raíz).

Para lograr el uso simultáneo de /tmp/snap.rootfs_XXXXXX y cambiar el nombre de /tmp/snap.$SNAP_NAME, se lanzaron dos instancias de snap-confine. Una vez que la primera instancia creó /tmp/snap.rootfs_XXXXXX, el proceso se bloquearía y una segunda instancia comenzaría con el nombre del paquete rootfs_XXXXXX, lo que provocaría que el directorio temporal de la segunda instancia /tmp/snap.$SNAP_NAME se convirtiera en el directorio raíz /tmp/snap. .rootfs_XXXXXX del primero. Inmediatamente después de que se completó el cambio de nombre, la segunda instancia falló y /tmp/snap.rootfs_XXXXXX fue reemplazado con manipulación de condiciones de carrera, como cuando se explotaba la vulnerabilidad de febrero. Después de la sustitución, el bloqueo de ejecución se eliminó desde la primera instancia y los atacantes obtuvieron control total sobre el directorio raíz instantáneo.

El último paso fue crear un enlace simbólico /tmp/snap.rootfs_XXXXXX/tmp, que fue utilizado por la función sc_bootstrap_mount_namespace() para vincular y montar el directorio real grabable /tmp en cualquier directorio del sistema de archivos, desde la llamada mount() sigue enlaces simbólicos antes del montaje. Este montaje está bloqueado por las restricciones de AppArmor, pero para evitar este bloqueo, el exploit utilizó dos vulnerabilidades auxiliares en multipathd.

Fuente: opennet.ru

Añadir un comentario