Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CSW2017 Qiang li zhibinhu_meiwang_dig into qemu security

1,632 views

Published on

CanSecWest2017

Published in: Internet
  • Be the first to comment

CSW2017 Qiang li zhibinhu_meiwang_dig into qemu security

  1. 1. Dig into qemu security Qiang Li & Zhibin Hu & Mei Wang /Qihoo 360 Gear Team CanSecWest 2017
  2. 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. 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. 4 QEMU introduction
  5. 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. 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. 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. 8 QEMU attack surfaces
  9. 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. 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. 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. 12 Attack from internal
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28 Attack from external
  29. 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. 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. 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. 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. 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. 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. 35 Thoughts in QEMU security study
  36. 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. 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. 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. 39 Thank you Qiang Li && Zhibin Hu && Mei Wang Gear Team, Qihoo 360 Inc liq3ea@gmail.com huzhibin@360.cn wangmei@360.cn

×