QEMU, bringing the guest closer to the host

  • Post author:
  • Reading time:6 mins read



Quick Emulator (or QEMU) is a cross-platform open-source emulator that performs hardware virtualization. QEMU is a free alternative to VMware. Xen, VirtualBox, KVM uses it and is available for most Linux distributions. Vishnu Dev, a security researcher, discovered that an attacker can break out of a guest operating system and attack the host operating system. QEMU Exploit vulnerability leads to a heap-based buffer overflow or arbitrary code execution and identifies with CVE-2019-14378. The researcher explains that this flaw is due to pointer miscalculation in-network backend of QEMU. Moreover, using a vulnerability management tool stops this vulnerability.

QEMU creates a SLiRP user network backend by default. Triggers the bug when large ipv4 packets reassembles for processing in SLiRP. However, patching this vulnerability with a patch management software can be very helpful.

Firtstly, there are two buffers allocated for IP fragments : m_dat and m_ext in mbuf . m_ext is used when m_dat is insufficient to hold the incoming packets. m_ext is allocated on the heap. Secondly, when a large fragmented packet arrives and space inside m_dat is not sufficient, then the m_ext is allocated.

  fig1. Allocation of buffers

But, the code does not handle the case when the very first fragmented packet is large and is allocated the m_ext buffer. The code assumes that the packets are present in m_dat . However, this leads to a miscalculation in the value of the pointer.

Uses the newly obtained value of the pointer in further calculations and modified, which now points to a wrong location. Moreover, attackers can use the values of ip_src and ip_dst  to write controlled data onto the calculated location. If the calculated values point to an unmapped location, QEMU crashes.

fig2. Calculation of delta with the assumption that packets are present in m_dat


QEMU Exploit:

The researcher explains that certain conditions met is to achieve arbitrary code execution,

  • Requires precise control over the heap to write controlled data relative to m->m_ext
  • Bypassing of ASLR and PIE requires leaks
  • The available function pointers do not support code execution. Hence uses arbitrary write.

When a new packet arrives, mbuf the object is allocated to store the packets until all the fragments have arrived. When all the packets have arrived, they are concatenated to one mbuf object. However, the attacker tries to spray the heap to increase chances of exploitation by using this mechanism.

Now an attacker tries arbitrary write in 4 steps:

  • Send a packet with id 0xdead and MF bit set (1)
  • Send a packet with id 0xcafe and MF bit set (1)
  • The m_len(amount of data in the buffer) of 0xcafe is overwritten to point to 0xdead‘s m_data
  • Trigger the reassembly by sending packet with id 0xcafe and MF bit set (0). This overwrites 0xdead‘s m_data with target address.
  • Send packet with id 0xdead and MF bit unset(0) to trigger the reassembly. This writes the required content to m_data.

Exploitation:

Before code execution, we have to bypass security implementations such as ASLR(Address Space Layout Randomization) and PIE(Proportional Integral controller Enhanced). SLiRP gateway responds to ICMP echo requests which bring back the data(payload) to the guest. Fake ICMP requests are sent to the host to receive the leaks from the host. Moreover, the ICMP header creates an arbitrary write, and the request sends it with the MF bit set (1). m_data overwrites to point to a fake title on heap. And, a packet with MF bit set(0)sent to end the ICMP request. However, we can achieve code execution using a fake QEMUTimer.

A QEMU developer has confirmed that this is not a host ring-0 exploit. However, as most production VM environments use tap networking and not SLiRP, this CVE would not be applicable to them. He also added that getting the root would require further attack to elevate privileges and escape SELinux confinement.


Affected Product in QEMU Exploit

QEMU with libslirp library version 4.0.0 on all platforms.


Impact

Successful exploitation of this vulnerability leads to denial of service or arbitrary code execution.


Solution

QEMU has released updates for all platforms. Please refer to this KB Article to patch using SecPod SanerNow.