从虚拟机逃逸看kvm-qemu虚拟化安全防御

Posted 2021-05-02 云吐槽

注：不知道是出于啥原因，很少找到对虚拟化安全防御相关的中文资料，去年很想写这个话题，但我家三星笔记本uefi硬是没法关闭导致无法从硬盘安装双系统又加上virtualbox不支持vt-x嵌套（试了N种方法未成），当然我也没有u盘，故在看完phrack上经典的vm escape文章后留下遗憾，然最近打开一年未开机的笔记本竟然发现解锁版vmware完美支持vt-x嵌套，经过一顿实验后，决定写写这个久违又很感兴趣的话题，抛错引玉也希望能看到更多的分享和资料。

本文分为如下章节：

1. 威胁建模/风险分析

2. 一个真实的逃逸实例

3. 逃逸监控

4. 逃逸防御
   

5. 应急响应 6谷歌怎么做的

1、威胁建模/风险分析

威胁建模是个很好的系统化进行风险分析的方法，在理解架构、数据流、攻击面时尤为重要。

kvm-qemu实现相对复杂，用尽量通俗的话描述一下。

补充一张网上摘来的KVM运行时图。

下图对数据流走向及信任边界进行了标识。

攻击面分析：

• guest-kvm模块
  kvm中特权／敏感指令的模拟，中断响应、切换vmx模式等只要在kvm中实现可被guest数据流触发的代码中存在漏洞被利用，kvm实现相对较轻量，所以漏洞相对较少。
  

• guest-qemu进程
  

qemu模拟IO／设备实现中存在漏洞被利用，目前主流公有云的采用了virtio半虚拟             化，而最多的漏洞出现在全虚的设备模拟。

• guest-透传的pci设备

• guest-宿主cpu

        guest代码在宿主cpu执行，cpu硬件漏洞也可能成为利用点。

存在的主要威胁／风险如下：

• guest逃逸到宿主机

• guest读取同宿主机其他guest数据

• 宿主机内核被guest拒绝服务／crash

2、一个真实的逃逸案例

a） 基于qemu全虚设备模拟的逃逸

详情可参考phrack文章，利用逻辑优美、执行稳定，是少有的可直接拿来验证/演示的实现，为作者点赞赞。（http://phrack.org/papers/vm-escape-qemu-case-study.html）

以下贴一些环境配置和利用后的结果展示。

#宿主机版本

[root@localhost ~]# uname -a
Linux localhost.localdomain 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

#qemu编译请参考文章
[root@localhost x86_64-softmmu]# ./qemu-system-x86_64 --version

(process:5659): GLib-WARNING **: 23:54:09.664: gmem.c:489: custom memory allocation vtable not supported
QEMU emulator version 2.3.93, Copyright (c) 2003-2008 Fabrice Bellard

#启动qemu

[root@localhost native]#  ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -display vnc=:89 -netdev user,id=t0, -device rtl8139,netdev=t0,id=nic0 -netdev user,id=t1, -device pcnet,netdev=t1,id=nic1 -drive file=/root/debian_wheezy_amd64_standard.qcow2,format=qcow2 --redir tcp:2222::22

#虚拟机配置

[root@localhost ~]# ssh root@127.0.0.1 -p 2222
root@127.0.0.1's password:

#虚拟机版本

root@debian-amd64:~# uname -a
Linux debian-amd64 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux
root@debian-amd64:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.11 (jessie)
Release:        8.11
Codename:       jessie

#gcc版本
root@debian-amd64:~# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10+deb8u2' 。。。
gcc version 4.9.2 (Debian 4.9.2-10+deb8u2)

#虚拟机外设，标黑的两个就是存在漏洞的实现。
root@debian-amd64:~# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)
00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20)
00:04.0 Ethernet controller: Advanced Micro Devices, Inc. [AMD] 79c970 [PCnet32 LANCE] (rev 10)

[root@localhost ~]# pmap -p 12223
12223:   ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -display vnc=:89 -netdev user,id=t0, -device rtl8139,netdev=t0,id=nic0 -netdev user,id=t1, -device pcnet,netdev=t1,id=nic1 -drive file=/root/debian_wheezy_amd64_standard.qcow2,format=qcow2 --redir tcp:2222::22
00007f9afbcff000   3076K rw---   [ anon ]
00007f9afc000000    700K rw---   [ anon ]
00007f9afc0af000  64836K -----   [ anon ]
00007f9b00000000 1048576K rw---   [ anon ]
00007f9b40000000   7908K rw---   [ anon ]
00007f9b407b9000  57628K -----   [ anon ]
00007f9b441c9000  55512K rw---   [ anon ]
00007f9b477ff000      4K -----   [ anon ]
00007f9b47800000   8192K rw---   [ anon ]
00007f9b48000000    136K rw---   [ anon ]

。。。

#执行逃逸

#宿主机验证qemu生成一个子进程sh，shellcode加了3个线程

[root@localhost ~]# pstree -alp
。。。
  |-sshd,3920
  |   `-sshd,11729
  |       |-bash,11733
  |       |   `-qemu-system-x86,12223 -enable-kvm -m 1024 -display vnc=:89 -netdev user,id=t0, -device rtl8139,netdev=t0,id=nic0 -netdev user,id=t1, -device pcnet,netdev=t1,id=nic1 -drive file=/root/debian_wheezy_amd64_standard.qcow2,format=qcow2 --redir tcp:2222::22
  |       |       |-sh,12376
  |       |       |-{qemu-system-x86},12224
  |       |       |-{qemu-system-x86},12228
  |       |       |-{qemu-system-x86},12230
  |       |       |-{qemu-system-x86},12377
  |       |       |-{qemu-system-x86},12378
  |       |       `-{qemu-system-x86},12379

[root@localhost ~]# lsof -p 12376
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
sh      12376 root  cwd    DIR  253,0     4096 33589946 /root/qemu/bin/debug/native
sh      12376 root  rtd    DIR  253,0      224       64 /
sh      12376 root  txt    REG  253,0   960392 50545940 /usr/bin/bash
sh      12376 root  mem    REG  253,0  2151672     6169 /usr/lib64/libc-2.17.so
sh      12376 root  mem    REG  253,0    19288     6175 /usr/lib64/libdl-2.17.so
sh      12376 root  mem    REG  253,0   174520    42891 /usr/lib64/libtinfo.so.5.9
sh      12376 root  mem    REG  253,0   163400       85 /usr/lib64/ld-2.17.so
sh      12376 root    0r  FIFO    0,8      0t0    54131 pipe
sh      12376 root    1w  FIFO    0,8      0t0    54132 pipe
sh      12376 root    2w  FIFO    0,8      0t0    54133 pipe
sh      12376 root   13r  FIFO    0,8      0t0    54131 pipe
sh      12376 root   16w  FIFO    0,8      0t0    54132 pipe
sh      12376 root   18w  FIFO    0,8      0t0    54133 pipe

[root@localhost ~]# pmap -p 12223
12223:   ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -display vnc=:89 -netdev user,id=t0, -device rtl8139,netdev=t0,id=nic0 -netdev user,id=t1, -device pcnet,netdev=t1,id=nic1 -drive file=/root/debian_wheezy_amd64_standard.qcow2,format=qcow2 --redir tcp:2222::22
00007f9afa4fc000      4K -----   [ anon ]
00007f9afa4fd000   8192K rw---   [ anon ]
00007f9afacfd000      4K -----   [ anon ]
00007f9afacfe000   8192K rw---   [ anon ]
00007f9afb4fe000      4K -----   [ anon ]
00007f9afb4ff000  11268K rw---   [ anon ]
00007f9afc000000    700K rw---   [ anon ]
00007f9afc0af000  64836K -----   [ anon ]
00007f9b00000000 917804K rw---   [ anon ]
00007f9b3804b000      4K rwx--   [ anon ]

b）kvm逃逸

搜索 http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=kvm，木有发现特别好的可以用来演示的例子，如有请共享给我。。。

3、逃逸监控

有了一个好的可复现的例子后，总结下监控点，用来做规则去监控逃逸。

• 第一个监控点

        qemu生成了子进程bash，据说现在比较好的是通过netlink收集进程信息。

• 第二个监控点

qemu部分内存被shellcode执行时设置了rwx，虽文章中提到并非必要去通过mprotect设置可执行内存，但是代码写得这么好，难免被人拿来去用。

• 第三个监控点

以上的特征都是基于攻击特征的梳理，安全监控难做的就是看的全、看的清、懂逻辑，最好的视野一定是在数据流链路上卡点去监控，越贴近实现越看的清、越懂逻辑。

• 第四个监控点

对kvm-qemu实现中关键路径的卡点，可以尝试对vmx.c中kvm_vmx_exit_handlers 实现中的卡点。

参考开源的kvm-vmi（https://github.com/KVM-VMI/kvm-vmi/）此项目实现了通过定制kvm增加陷入环节实现了对虚拟机中geust系统调用进行监控，没有实践过，不予置评，但是为他点赞，国人写的。

• 第五个监控点

对宿主系统调用进行监控，比如用auditd等等方式，嗯，这个适用于各种攻击的监控。。。

5、逃逸防御

• 加固qemu二进制

1、删除无用的设备实现，尽量采用出现漏洞较少的外设。

2、在qemu编译过程中进行执行安全编译。

参考https://docs.openstack.org/security-guide/compute/hardening-the-virtualization-layers.html

• 加固KVM

对kvm中模拟的各种指令代码进行限制，删除无用的中断处理实现等等，建议找个对kvm精通的人干这事吧。

• qemu降权/chroot运行

qemu支持chroot和切换到普通用户运行-runas dd -chroot /opt/dd/

• 基于kvm-qemu执行关键路径的防御

5、应急响应

• 别慌，首先区分是qemu的漏洞还是kvm的漏洞，对kvm-qemu的架构要有个基本的认识。

• 如果是qemu，请看自己是否受影响

以此漏洞来看，qemu支持的网卡类型，支持但是没有用不会受影响。

[root@localhost native]#  ./x86_64-softmmu/qemu-system-x86_64 -net nic,model=?                                                       

(process:9300): GLib-WARNING **: 01:29:55.963: gmem.c:489: custom memory allocation vtable not supported
qemu: Supported NIC models: ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet,virtio

从vm看加载的设备

root@debian-amd64:~# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)
00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20)
00:04.0 Ethernet controller: Advanced Micro Devices, Inc. [AMD] 79c970 [PCnet32 LANCE] (rev 10)

• 如果是kvm，请升级相关模块或操作系统内核。

• 建立热补丁能力

1、qemu应用热补丁，ucloud写了很好的文章（http://blog.ucloud.cn/archives/2235），建议开源。。。

2、kvm内核热补丁，请自行找资料

6、google怎么做的

参考：

http://www.googblogs.com/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext/

http://events.linuxfoundation.org/sites/events/files/slides/KVM%20Hardening.pdf

简单翻译一下：

1、我们的人很牛，挖了很多kvm的漏洞。

2、我们对KVM进行了裁剪，在考虑性能的情况下，把大部分在内核态实现的代码移植到了用户态。

3、我们觉得qemu很臃肿不好，安全测试不足，自己写了一个取代它。

4、没看懂放在这是啥意思。

5、我们的配置管理，可以知道哪个版本的kvm在运行，如何配置，如何部署的，同时对系统启动链做了完整性检查，包括用户的镜像。

6、我们可以快速对漏洞进行响应。

7、我们严格控制发布，确保只有一小撮人可以接触到kvm的构建和发布系统。