After a relatively long period without a potentially-catastrophic vulnerability to report, we must again break out the hard hats as the numerically-improbable ‘CVE-2015-3456‘ is here and it wants to kill your datacentre. It’s called VENOM, in case you were wondering.
Oh not again…
No, not again, this is nowhere near as bad as 2014’s raft of terrifying shell and cryptographic security holes that had teams across the world working late into the night. That being said, VENOM isn’t something you can ignore if you are responsible for a virtual machine host or cluster that uses the QEMU software framework; this includes:
- Linux Kernel-based Virtual Machine (KVM)
- Citrix Xen
To be absolutely clear, Microsoft Hyper-V, VMware products and others are not affected.
The VENOM bug
In the proud tradition of backronyms like POODLE and GHOST, VENOM stands for ‘Virtualized Environment Neglected Operations Manipulation‘. The VENOM bug does not target the operating systems of the guest VM nor the host on which it runs; instead, it is the QEMU ‘hypervisor‘ that is at risk of exploitation. The VENOM bug is described in OxCERT Security Bulletin OSB2015-060
The hypervisor code sits between the guest and the host, operating as the ‘bridge’ and abstraction layer relied upon by either side to communicate with the other. This hypervisor code is minimalist but wide-ranging, incorporating all of the memory mapping and device drivers required to trick the guest into believing it is operating on real hardware.
One of the functions of the hypervisor is to supply a virtual storage device to the guest OS; most often this is a virtual hard disk file held on the host, or an installation ISO file held in a virtual optical drive container. For the sake of compatibility with ancient and archaic systems, most hypervisor code comes with an emulated 3.5″ floppy drive option, and QEMU is no exception.
Due to the sheer unpopularity of even emulated floppy disks, this code is rarely invoked and even more rarely actually used in production, but the hypervisor nonetheless maintains a driver infrastructure for the ancient medium, and it is here that we find our VENOM bug.
A successful exploitation of the VENOM bug allows a program inside a Virtual Machine to ‘break out‘ of its guest OS jail, and to run arbitrary commands against the host operating system. Hypervisors need a relatively large privilege space if they are to accomplish their tasks, and any attacker able to exploit this bug can therefore do anything on the VM host that the hypervisor can do. Because the bug attacks the hypervisor code itself, it is platform-agnostic and may affect any host running the vulnerable QEMU code. It is relatively easy therefore, for a single attack to escape from an otherwise highly-secure VM, and break out into neighbouring ‘isolated’ VMs with minimal trouble.
Even if proper precautions have been taken and the hypervisor is assigned least privilege on the host OS, it would still be possible for an attacker to interfere with other virtual machines on the same host, operating as they do under the same global hypervisor process. Fortunately, the announcement describes an exploit of this bug to be ‘non-trivial’ and PoC code is not available publicly, so hopefully it will be possible to patch before any real harm is done.
No ‘in-the-wild’ exploitations of VENOM have been observed at time of writing, and it should be noted that at present this is a local attack only; without first leveraging other vulnerabilities, an attacker would require user-level access to a guest VM. However, it is not uncommon to see communal VMs left relatively unsecured, on the basis that the virtualised infrastructure will minimise the extent of any abusive user behaviour; this is no longer true, any user on an affected system must be considered capable of executing code against the host Operating System, effecting arbitrary changes in the guest VM and beyond.
The discovery outlined in CVE-2015-3456 describes a technical attack against QEMU’s virtual Floppy Disk Controller (FDC). The prerequisite for exploitation is that an attacker is able to issue device commands to this FDC; please note that even if an administrator has disabled the emulated floppy disk, the commands may still be interpreted by the FDC.
The FDC code expects disk commands to arrive with a specific data payload, and as such allocates a fixed buffer to receive the data from whichever application wishes to access the drive (can you see where I’m going with this?). Certain commands do not properly handle their memory indexes, and thus will write to FIFO memory if supplied with too much data as a parameter.
By crafting a specific floppy disk command and aiming it at the FDC’s virtual interface inside the guest operating system, the attacker can overflow this fixed buffer. As with most buffer-overflow attacks, this one can be leveraged in a variety of ways, but the most common outcomes will be either a Denial-of-Service condition (by crashing the FDC and/or the hypervisor) or more seriously, the potential for arbitrary code execution in the context of the hypervisor process.
Mitigation and Resolution
Fortunately, software vendors are aware of the bug and are patching it ahead of any potential Proof-of-Concept code releases; provided vendor patches are applied swiftly, there is minimal potential for exploitation at this time. Patches are available for all major platforms, although it is worth verifying that they are being properly applied.
Any operators of KVM, Xen or QEMU-based virtual machine clusters are advised to patch as soon as possible; further, many network appliances make use of this code behind their proprietary interfaces, and it is not always clear which vendors are making use of this code.
Check with your vendors, and if you run an appliance that operates any form of internal virtualisation it is worth seeking updates for it also.