Today, a new vulnerability was disclosed by the name of VENOM (CVE-2015-3456), already seeing a fair amount of media attention. In order to help you assess the impact of this vulnerability on your systems, we are collecting background information and provide a prelimary risk assessment for our products.

What this attack is all about

The gist of this vulnerability is that there is code in a piece of software called qemu that emulates a floppy disk drive. qemu is being used heavily by open source hypervisors like XEN and KVM.

The qemu floppy disk driver is not a paravirtualized device like virtio-block, but really a physical device is being emulated. A kernel driver running in the guest operating system talks to it by reading and writing (emulated) I/O ports, just like it used to do on real hardware some time in the previous millenium when floppies were actually still in use. The x86 machine instructions for accessing I/O port registers are inb and outb (plus a few variants thereof), in case you’re interested.

Of course, accessing I/O ports is a privileged operation, and code doing so either needs to run inside the (guest) kernel, or has to have root privileges at least (the iopl() system call can be used by root processes to grant themselves privilege to access I/O ports even from a user space program).

The floppy emulation code has been around for a while, and it has had a bug all along. Depending on timing and a few other parameters, it is possible for a privileged process in the guest to issue a sequence of outb instructions that overflows a buffer in the floppy emulation code of qemu running on the host side. So far, proof-of-concept code exists that shows that it is possible to at least crash qemu.

Why is that a problem? Because it allows malicious code the guest to at least wreak havoc in the host, or worse, execute code in the host context and escape from its guest confinement.

To make things worse, qemu will enable the floppy driver by default unless invoked with the -nodefaults option. So, this looks like quite a venomous little viper snaking its way out of its sandbox.

Is this virtualization doomsday?

It’s too early to say yes or no. Currently, no code execution exploit is known. This may change, of course.

Contrary to earlier research done by us, invoking qemu with the -nodefaults option does not close the loophole completely.

Where can I obtain additional information?

As I write this, SUSE is in the process of creating and releasing updated packages to address this issue. Please check this knowledgebase article for updated information on the vulnerability, and watch suse.com/support/update or our CVE database for our upcoming security advisory.