A vulnerability in QEMU—a popular open-source hardware virtualization package—allows malicious actors to perform a "virtual machine escape," in essence, allowing attackers to break out of guest operating systems and attack the host operating system that QEMU runs on. Like the VENOM vulnerability disclosed in 2015, the vulnerability potentially allows attackers to execute code at the same privilege level as QEMU itself, or crash the QEMU process entirely.

The vulnerability, designated as CVE-2019-14378, relies on the networking implementation in QEMU: A flaw in the SLiRP networking backend exists in the ip_reass() routine—used to reassemble packets—when the first fragment is larger than the m->m_dat[] buffer. Fragmentation of packets is a routine occurrence, for situations when packets are larger than the maximum transmission unit (MTU) set for a specific connection. In these situations, the fragments are reassembled by the receiving system.

SEE: Launching a career in cybersecurity: An insider's guide (free PDF) (TechRepublic)

Successfully exploiting the vulnerability also requires bypassing ASLR and PIE. A full explanation of the exploit is provided by Vishnu Dev. Though full exploitation is moderately more difficult than the VENOM attack, Dev's proof-of-concept video demonstrates it running on a Linux desktop, by opening a GNOME Calculator process on the host machine from a shell script inside QEMU.

While no external mitigation exists, patches have been published for the vulnerability, which additionally fixes a regression in which network block device connections could hang.

The vulnerability was found during a code audit, not through finding an infected system. To date, there is no indication that this has been exploited in the wild. Naturally, patches applied to QEMU typically require a restart of the virtual machines operated by that process, which will inevitably create downtime as systems are patched. Some providers of cloud-hosted virtual machines utilize QEMU for virtualization, and may be vulnerable to this flaw.

For more, check out "Google Cloud charging for IPv4, but proper IPv6 support is still missing in action" and "Vulnerability in VxWorks RTOS allows attackers to control internal networks" on TechRepublic.

Also see

This article was originally published on TechRepublic.