"Venom": new vulnerability affecting BigV and legacy VMs (CVE-2015-3456)


#1

CVE-2015-3456, aka “Venom”, is a security vulnerability in the floppy drive emulation used by the Qemu, KVM and Xen virtualization platforms.

This vulnerability potentially allows an attacker to escape from the confines of an affected virtual machine, gaining access to execute code on the host system.

We are not aware of any code to exploit this vulnerability that is in the wild right now.

Is my virtual machine affected?

Yes, both BigV and legacy virtual machines are affected.

Given how much control this vulnerability could give an attacker, we’re proactively updating both BigV and the legacy virtual machine platform to eliminate this vulnerability.

Do I need to do anything?

BigV users

No. We are patching BigV to eliminate this vulnerability.

We are in the process of migrating customers’ virtual machines to hosts that have been patched to eliminate this vulnerability.

You will not need to reboot your BigV virtual machine, nor should you see any impact on running services.

We will update this thread when the live-migration is complete.

Legacy VM users

Your legacy virtual machine must be rebooted as we have now deployed a patch to the platform.

Please reboot your legacy virtual machine as soon possible. Machines that have not been rebooted will be automatically rebooted starting from Friday 15 May 2015, 0700 UTC +1.

Dedicated servers

Dedicated servers are only affected if you are using qemu or xen to run your own virtual machines.

In this case, we strongly recommend you apply the latest package updates on your dedicated server as early as possible. If you are a managed customer, we can assist – please email support@bytemark.co.uk.

Xen users: see http://xenbits.xen.org/xsa/advisory-133.html for more information.

Further reading


https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/


[Resolved] Host08 Networking Issues
[Resolved] Emergency maintenance on legacy virtual machines 15 May 2015 0700 UTC+1
#2

My BigV has been live migrated to a patched host node without any downtime at all. ZNC maintained IRC connections throughout. Massive kudos to BigV/Bytemark!


#3

Josh, just for clarity on the legacy VM reboots: will this be a reboot of the underlying physical host (and therefore could happen at any moment) or will it be a reboot of each guest at a time of their choosing (although preferably sooner rather than later of course)?

Thanks.


#4

Hi @openstrike: as you can imagine, it’s quite a big job to deploy this patch to our legacy VM platform! We’re working on it now and we intend to have a plan to share with everyone tomorrow morning in the next post down :slight_smile:


#5

Legacy VM update

Your legacy virtual machine must be rebooted urgently as we have now deployed a patch to the platform. This does not apply to BigV.

Please reboot your legacy virtual machine as soon possible. Machines that not been rebooted will be automatically rebooted starting from Friday 15 May 2015, 0700 UTC +1.

We are also emailing all the impacted customers directly.

Thanks for your patience whilst we’ve worked to patch and eliminate this serious vulnerability.


#6

BigV update

OK, I’ve just finished patching all the BigV hosts. Unlike the legacy platform, this is a zero-downtime procedure (with a few minor caveats I hope we’ll be able to document properly tomorrow).

We became aware of the vulnerability at around 1400 UTC+1 and patching was complete by 1730 UTC+1, which I’m fairly pleased by. If you did notice anything odd, or experienced an unexpected reboot during this time, do let us know, but I think this is one of our more successful qemu vulnerability live patching adventures!


[Resolved] Emergency maintenance on legacy virtual machines 15 May 2015 0700 UTC+1
#7

If anyone has a problem with their legacy VM not restarting after reboot, and have recently upgraded to Jessie, then you’ll probably need to update to a newer kernel.

In the admin console, you’ll see an error like this at the end of the log
systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file or directory

Switching to the kernel linux-3.4.106-kvm-i386-20150402 fixed it for me, and all seems to be functioning again.


#8

All the legacy VMs have now been rebooted. Thanks to everyone for their patience.