For Venom security flaw, the fix is in: Patch your VM today

ZD Net ^ | 13 May 2015 | Steven J. Vaughan-Nichols

[ShadowAce]

Venom (Virtualized Environment Neglected Operations Manipulation), the recently discovered security hole in the open-source QEMU virtual machine hypervisor, has been fixed.

That's the good news. The bad news is many of you, even though you may use a QEMU-based hypervisor on your server or for your cloud, think you've nothing to worry about. You do.

Venom, as described by its discoverer, Crowdstrike, an end-point security company, works by attacking QEMU's virtual Floppy Disk Controller (FDC). The first thing many of you think when learning this is: "Who cares, I've never used a floppy drive on my virtual machine (VM)!"

Ah, but, you don't have to activate the virtual floppy drive for a potential hacker snake to bite you. By default, the legacy floppy drive code is still in there, even though it's never been used. The corruption is still hiding in the code. So, even though you'd never dream of using a VM floppy drive, you're still open to attack.

Indeed Crowdstrike maintains that "even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers."

Therefore, if you are running QEMU, or virtualization stacks that use it, such a Xen, KVM, and Oracle's VirtualBox, you could be hacked.

Some cloud systems that rely on these are not vulnerable. Amazon Web Services (AWS), for example, uses Xen, but Amazon states, "There is no risk to AWS customer data or instances." In addition, non-QEMU-based hypervisors, such as VMWare and Microsoft Hyper-V, are safe. Check with your VM or cloud provider to see if you're safe if you're not sure.

A successful attack still wouldn't be easy. It requires a user to have administrative or root access to the VM. But, CrowdStrike claims that with Venom, attackers can jump from one VM to another. So, in theory, a single insecure VM could be used to successfully assault other VMs or the underlying operating system.

True, there are no known exploits... yet. But, Venom is a simple memory buffer overflow hole. It can be exploited on any operating system, which supports QEMU virtualization or hypervisors. That includes, Linux, Mac OS X, Solaris, and Windows. In short, writing an exploit is trivial. This makes Venom a serious security problem that must be addressed. You can't walk it off.

Fortunately, the fixes are in.

The QEMU fix itself is now available in source code. Red Hat has been working on the fix since last week.

Xen, noting that any Xen system running x86 VMs are vulnerable, has released fixes for Xen 4.2.x and later. If you're using an earlier version of Xen, upgrade and apply the patch.

VM hypervisors that aren't based on QEMU, such as VMware, Microsoft Hyper-V, and Bochs hypervisors, are immune to Venom attacks.

All versions of Red Hat Enterprise Linux (RHEL), which includes QEMU, could be attacked. Red Hat recommend that administrators update their system using the commands, "yum update" or "yum update qemu-kvm." Once this is done, you must "power off" all VM guests for the update to take place. Restarting the guest operating system is not enough because it would still use the old QEMU binary.

Anyone running a Linux server with QEMU installed should follow Red Hat's general instructions. For example, on Debian and Ubuntu, update your system with the following commands:

sudo apt-get clean

sudo apt-get update

sudo apt-get upgrade

power off your VMs, restart them, and you'll be safe.

SUSE Linux is also vulnerable, but the SUSE Cloud is not. While SUSE is still prepping its Venom fix, the company recommends that you can work around the problem on SUSE Linux Enterprise Server (SLES) 11 and 12 by managing your VMs with libvirt. This VM toolkit supports KVM/QEMU, Xen, and Virtualbox. It protects you from Venom by automatically starting VMs with "nodefaults," which means QEMU-based VMs shouldn't have access to the bad code.

Oracle has yet to release a fix for VirtualBox. Oracle software lead Frank Mehnert told ZDNet, "We will release a VirtualBox 4.3 maintenance release very soon."

So, by promptly patching your system and then turning off and on your VMs, you should be safe. So, do it now, don't wait for some sidewinder of a hacker to come up with an exploit and bite you.

[ShadowAce]