CanSecWest2017

1. Dig into qemu security
Qiang Li & Zhibin Hu & Mei Wang
/Qihoo 360 Gear Team
CanSecWest 2017

2. About us
2
l Qihoo 360
l One of the most famous security company in China
l Gear Team
l Mainly focus on the cloud security
l Xen, QEMU, OpenSSL, NTP, Firefox, etc
l Very young and passional team
l 100+ CVE last year
l Especially 70+ CVE from QEMU

3. Agenda
3
l QEMU introducKon
l QEMU aLack surfaces
l ALack from internal
l ALack from external
l Thoughts in QEMU security study

4. 4
QEMU introduction

5. QEMU introduction
5
l Qemu is widely used emulator, it can do Full
system/User mode emulaKon
l Implement in SoRware
l Accelerated by KVM/XEN

6. QEMU introduction
6
l QEMU is a normal user mode process
l QEMU’s virtual address space is used as
guest’s RAM
l QEMU’s thread act as guest vCPU

7. QEMU introduction
7
l Qemu communicate with kvm through
kvm char device
l Generally guest code can directly run on
naKve cpu
l When running sensiKve instrucKons, it will
trap into kvm by vm-exit instrucKon, code
control transfer from qemu to kvm
l If the exit event is IO event, it will then
dispatch to qemu

8. 8
QEMU attack surfaces

9. QEMU attack surfaces
9
l Most security issue is caused by handling
untrusted data incorrectly
l Important thing is the data flow and what data
we can control
l Data from internal, mainly from the guests,
most from guest’s device emulator
l Data from external, vnc/spice/qmp, etc

10. QEMU attack surfaces - from internal
10
l Device emulaKon of qemu has lots of
vulnerabiliKes include some criKcal ones
l Full emulaKon is discussed a lot, but virKo is not,
virKo is very useful for improving performance,
we will talk about virKo later
l For convenience, most virtualizaKon product
install a agent in the guest, qemu has its guest
agent(qga), not powerful as vmware tools and
less vulnerable

11. QEMU attack surfaces - from external
11
l VNC is used for remote desktop access, not only
used in VMs
l Spice is like vnc, but usually used for remote access
to VMs, contains four parts : protocol, client,
server, guest
l QEMU Machine Protocol(QMP), lightweight text
based protocol, allows applicaKon interact with
QEMU
l Malicious image

12. 12
Attack from internal

13. Attack from internal - device emulation
13
l Qemu device emulators are the biggest
source of vulnerabiliKes
l Full virtualizaKon / paravirtualizaKon
l The 3rd library drivers, like virglrenderer

14. Attack from internal - device emulation
14
l Most of the devices are based on soRware
emulaKon
l Guest is unaware of the underlying
virtualizaKon environment, so qemu will do
lots of work to implement it
l There are many devices should be
emulated, such as different kinds of disk,
network card, etc

15. Attack from internal - device emulation
15
l PCI devices expose BAR(Base
Address Register) to OS, so OS can
interact with devices, QEMU
should provide this layer in device
emulaKon as well
l The guest OS interacts with the device by reading and wriKng
to the BARs registered by the device, this operaKons trap into
the KVM and dispatch back to QEMU callback handlers which
are registered while device iniKalizing

16. Attack from internal - device emulation
16
l If we don’t consider about KVM, just regard
it as a simple proxy
l Guest data is untrusted and can be malicious, it will cause
vulnerabiliKes in QEMU
l Data flow would be simplify :
Guest -> QEMU

17. Attack from internal - device emulation
17
l Two types of BARs: IO port & MMIO
l We can read/write IO port/MMIO to trigger flaws in QEMU
l Malicious kernel module can act
as a device driver by reading or
wriKng its BARS

18. Attack from internal - example
18
l We found a flaw in Cirrus VGA driver
l When VGA copy data by Bitblt in backward mode
will trigger this bug
l We can use it to do OOB read/write

19. Attack from internal - example
19
It is the patch for this bug, when calculate min variable, it
forgets to decrease s->cirrus_blt_width and cause the
OOB read/write
It is the execuKon flow, when guest write to vga io port, kvm
dispatch the io event to qemu cirrus vga driver

20. Attack from internal - virtio
20
l VirKo is for io paravirtualizaKon
l It has front-end in guest, back-end in qemu
l They do data exchange by vring mechanism

21. Attack from internal - virtio
21
l The guest add data to vring’s in buffer, when
the data is ready, it will trigger a kick to noKce
QEMU
l QEMU receive the noKce and pull the data from
guest and process it
l ARer QEMU completely handle the request, it
will push the result to vring’s out buffer
l Malicious guest can write corrupt data to qemu
through vring

22. Attack from internal - virtio
22
l Every virKo device has one or more
vqueues, and every vqueue has a handler
to process data
l During device creaKon, it register the
handler to the vqueue
l In the callback, it will pop the request
from guest and then process
l Every virKo device has the same data
processing model

23. Attack from internal - example
23
l VirtFS is a paravirtualized
filesystem, used to share files
between host and guest
l It uses virKo model, we can see v9fs
client in the guest and v9fs server in
the qemu, they exchange data
through vring

24. Attack from internal - example
24
l V9fs has a vqueue handler for every
request, like v9fs_read funcKon
l It will unmarshal the arguments from
guest, and most important thing is the
arguments are totally controlled by guest
l Vulnerability would occur if the handler
failed to do sanity checking carefully

25. Attack from internal - example
25We found a flaw in v9fs driver, it is a integer overflow bug, write_count is signed integer, but off and count is unsigned, when they
do subtracKon, it will cause integer overflow, and then trigger buffer overflow via memcpy

26. Attack from internal - third party library
26
l QEMU uses some third party libraries, like gpu virKo device
l Virglrenderer is a third party library, and QEMU gpu device
uses it to accelerate 3D rendering
l A lot of vulnerabiliKes we found in this lib
CVE-2017-6386, CVE-2017-6355, CVE-2017-6317, CVE-2017-6210,
CVE-2017-6209, CVE-2017-5994, CVE-2017-5993,CVE-2017-5957,
CVE-2017-5956, CVE-2016-10214, CVE-2017-5937,CVE-2016-10163,
CVE-2017-5580

27. Attack from internal - third party library
27
FuncKons in the red box have been found vulnerabiliKes,
because they failed to check data carefully
Let us recall the framework of virKo in the leR picture

28. 28
Attack from external

29. Attack from external - vnc
29
l VNC is for desktop sharing system
based on RFB protocol
l QEMU has a built-in vnc server
l Several vulnerabiliKes has been found
in this module

30. Attack from external - example
30
We found a DOS bug in VNC module. When we set red_max to zero, it will crash the qemu via divide by zero

31. Attack from external - spice
31
l Spice is an another way for remote
accessing to guest
l It has four parts : Protocol, Client,
Server and guest
l VulnerabiliKes can exist in
somewhere :
qxl driver in guest -> device in QEMU
spice client -> spice server in QEMU

32. Attack from external - example
32
We discover this issue alone, but someone has been already found it. This issue can be triggered by remote client. When
client connect to spice server in QEMU, it will call reds_handle_read_link_done funcKon, the link_mess variable is the packet
pointer, and num_channel_caps and num_common_caps are all controlled by remote client, it can trigger a integer overflow
bug, and then cause memory corrupt

33. Attack from external - qmp
33
l HMP/QMP is used to interact with QEMU
l Lightweight, text-based data format
l Very useful, such as capabiliKes negoKaKon,
device (un)hotplug …

34. Attack from external - example
34
We found a flaw in hmp module, it triggers array out of range
access, then cause memory corrupt

35. 35
Thoughts in QEMU security study

36. Thoughts in QEMU security study
36
l Audit code by some people viz. code review
- limit by energy, brain memory, associaKve ability …
l Fuzzing
- limit by comprehending program behavior …
l Both ways have shortcomings

37. Thoughts in QEMU security study
37
l Fuzzing is using a model repeatedly trying and
learning
l SomeKmes we can’t establish the model or
implement it
l So we would say “This flaw can not be found by
fuzzing”

38. Thoughts in QEMU security study
38
l The most efficient way to find bugs is :
Knowledge + fuzzing
l AFL just knows a liLle more about program running,
but it is far more efficient than dumb fuzzers
l Knowledge is important, fuzzing is efficient, combinaKon is complex:
we’re conKnue improving our methods to find bugs, and may share
new studies in the furture

39. 39
Thank
you
Qiang Li && Zhibin Hu && Mei Wang
Gear Team, Qihoo 360 Inc
liq3ea@gmail.com
huzhibin@360.cn
wangmei@360.cn