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.
The elephant in the room is that only the open source emulators are affected?
To those that say that no one uses floppy disk controllers - almost all VM tools are loaded into machines via floppy images.
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?
Because it's important to make sure people know what a great name/logo your exploit discovery has.
Free Software brand names are outstanding and compatable with the new and innovative themes in industry!
(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.
Seriously, not all of us are 15 years old and have nothing better to do than sit around picking with kernel configs. Unlike you, some of us use computers to accomplish things other than bragging about all the crap I've compiled by hand for custom configurations.
My solution? Don't use Xen/QEMU/VirtualBox. They're all pretty shitty when compared to something like VMware. oVirt and OpenStack are monstrous piles of crap. They are free ... yet its way cheaper to pay for over priced VMware and not spend your time picking around with silly weaknesses in the OSS hypervisors since they all copy each other and run essentially the same code in all of them ... hence this exploit. They're ALL based almost ENTIRELY on QEMU, hence all of them being exploitable.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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?
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
This sh*t erased all the floppies in our data center through QEMU.
This is why SmartOS runs KVM within a Zone!
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 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."
I note that the two proprietary systems were not impacted. Of course all software has bugs and vulnerabilities without regard to open source or proprietary, but here on slashdot we like think that open source is always the better option. This is not always the case.
The phrase "almost every virtualization software" is used, but the list of items given has three pieces of software that are impacted and three that are not. In terms of virtualization systems that are in production use by business, I would think that VMware and Hyper-V would take the lion's share (as they are commercial and "supported"), thus being a candidate for "almost every". I think the phrase should have been "almost every open source virtualization software".
In my experience, Xen, KVM, and others are "free"... but you pay a lot for man-hours to get them set up and running. For a university, that's fine -- there are a lot of students and interns to throw at an OpenStack setup in order to get it running.
However, in the real world, you want something that works and does its job right, even if one has to deal with licensing fees. Hyper-V is OK, but by far, the best solution out there for non-trivial virtualization projects is VMWare's offerings. Since VMWare can run either as a type 1 hypervisor (ESXi) or a type 2 hypervisor (VMWare Fusion/Workstation), it has a lot of utility, from running a VM on a laptop to mitigate damage if a web browser gets infected [1], to being the core infrastructure of a company, adding failover protection and even true high availability [2]. Other than items which need to be run on bare metal (specialized hardware, vital tasks), it is not a matter of why run virtualized... but why not.
[1]: SSDs are a must for this, since it requires a lot of random access.
[2]: The true high availability, or Fault Tolerance, runs two VMs in lockstep on different machines, and if one dies, the other takes up immediately, no reboot of the VM needed. Downside is only one vCPU can be used... so this won't work for that high I/O Oracle backend. However, for things like DNS servers, KMS servers, and other lightweight, but essential tasks, it comes in handy.
It may not be too easy to exploit but impact is pretty critical. FreeBSD's Bhyve not affected.
Comcast uses openstack any want some free hbo?
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
Link to the actual Xen Advisory.
http://xenbits.xen.org/xsa/adv...
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.