Slashdot Mirror
'Venom' Security Vulnerability Threatens Most Datacenters
An anonymous reader sends a report about a new vulnerability found in open source virtualization software QEMU, which is run on hardware in datacenters around the world (CVE-2015-3456). "The cause is a widely-ignored, legacy virtual floppy disk controller that, if sent specially crafted code, can crash the entire hypervisor. That can allow a hacker to break out of their own virtual machine to access other machines — including those owned by other people or companies." The vulnerable code is used in Xen, KVM, and VirtualBox, while VMware, Hyper-V, and Bochs are unaffected. "Dan Kaminsky, a veteran security expert and researcher, said in an email that the bug went unnoticed for more than a decade because almost nobody looked at the legacy disk drive system, which happens to be in almost every virtualization software." The vulnerability has been dubbed "Venom," for "Virtualized Environment Neglected Operations Manipulation."
I've get to some across a virtual server provider that has a floppy disk driver enabled. Seems a lot of hype about nothing to be honest and scaremongering.
What is the use case for virt floppy? Drivers nearly never fit, VM's should not need firmware updates. SO why would people still be exposing a virt floppy to VM's?
No sir I dont like it.
finding a full name that fits the really cool "venom", instead of actually going about fixing it.
This must be a very serious vulnerability judging purely by it's name.
I love how even if the floppy drive is disabled, this is still exploitable due to another unreleased bug.
The solution is just to get rid of all the old unmaintained code by default. If someone wants to use old deprecated code, let them apply the patches themselves.
The Linux kernel is a goldmine of barely maintained crap that hasn't had more than 2 users for the least 30 years. Not breaking userspace is nice, but at some point you need to take into account the huge gaping security risks of mistery legacy code running with maximum privileges.
No one was able to review the closed source ones.
The open source tools were vulnerable from 2004 to 2015.
The closed source ones? Nobody knows. And that's really scary.
Odd... all of the VM tools that I install are either by the OS's package manager, or by mounting a CD ISO. No floppies.
Not to get too far offtopic, but as a long-time user of open source software, it bothers me that open source software seems to have inferior names for its applications (GIMP, Yakuake, etc) but very marketing-friendly names for its vulnerabilities (Heartbleed, Shellshock, Venom). If you look at closed-source software it is the complete opposite - applications have marketing-friendly names while vulnerabilities are called something like "KBstringofnumbersnobodywillrememberorcareabout". So are open source developers just much better at naming vulnerabilities or are the marketing departments of closed software companies quietly assisting with the naming of open-source vulnerabilities?
Not sure where you are getting this floppy business from. Virtualbox guest addition tools are loaded from a single CD image. All the driver packages are on that image. Hyper-V also uses a CD image. I have also used VMware in the past and they too used CD images.
Perhaps you are confusing that with the provided floppy controller emulation.
(CVE-2015-3456)?
I've got the same vulnerability designation on my luggage!
There's got to be some test I can run on my VMs to see whether or not I'm vulnerable, right?
Gvenom
Kvenom
GNUvenom
FreeVenom
OpenVenom
venom-1.0.7-RC2
Venom.js
If your computer experience involves apply patches as part of normal operations, you've completely and utterly failed to understand that computers are there to relieve work from you, not make you work harder.
So those engineers at RedHat who produce the bug fixes for the rest of is, they fail to understand what exactly?
global warning will make all disks floppy
So every single vulnerability from now on is getting an idiotic media name?
We can't have CVE-1234, no no, must be RageBoner or PantShitter or no one will take it seriously!
sic transit gloria mundi
There's a recent post on the openstack-operators mailing list talking about this, but the basic gist is that pretty much all versions of qemu are susceptible to the bug, but that in practice it's not quite as big a deal as it sounds.
The thing to note is that the major linux distros by default enable something called "sVirt" which basically locks down qemu to using only the resources that have been explicitly assigned to it. This should make it hard (ideally impossible) to break out and compromise the host or other qemu processes.
Also, on most major linux distros qemu doesn't run as root but rather as a separate user with lower privileges.
The problem is that virtual machines are often used to run legacy software on modern hardware, cutting out the legacy cruft by default would cut off all those users... Although having it configurable at runtime would be much easier for users than having it a compile time patch.
Some of us do make hardened builds removing unwanted crap, but having the hardened option require the extra work is more practical from a usability point of view as those of us who care most about it tend to be the most capable of making the changes.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
But what if you're running your VM within a VM? Will the malware know it's still in a dream?
The last time I did some ESXi troubleshooting (about two weeks ago), I had to look up documentation that I would think our "system admins" would already know. I personally don't even know that much about the actual nuts n bolts of it yet, but our Indian sysadmins really won't do anything without someone like me beating them over the head with step-by-step instructions for the entire maintenance window. "Enter this command"...silence on the phone..."now hit Enter"...it's ridiculous.
I blame this on the British, who beat this whole "do not act first, always ask" meme into the Indians during the colonial times. I so want to tell them "You work for an American company now, just GET IT DONE!" Sometimes it even gets to the point where SMT (Situation Management, the team that coordinates all our SEV1 / SEV2 issues) had to tell them "He is not your technical adviser, you need to keep trying to contact XYZ and bring them on this call" lol
in the article, it does say that neither HyperV nor VMWare are affected by this...so in reality about 80% of VM's are safe lol
Xen security advisory notes that Xen paravirtualized setup is not vulnerable. It only strikes HVM, where the host OS is run unmodified and think it has access to a real floppy drive.