Thanks to Mike Wood and Andrew Ludgate of SophosLabs
for their behind-the-scenes work for this article.
Plenty of vulnerabilities have been fixed in the past week, with at least Adobe, Microsoft, Mozilla and Apple delivering dozens of critical security fixes for software that includes three of the Big Four browsers.
But none of those patches were made to sound exciting, or given funky-sounding names, so they didn’t get much media attention.
VENOM, on the other hand, has had a fair amount of coverage.
It’s not a witty name, like Heartbleed (you could bleed off data via a TLS heartbeat, so that one was an amusing play on words) or Shellshock (another pun based on the fact that the bug was some shockingly bad coding in the command shell).
VENOM is a backronym – a word that was chosen for its marketing punch and then expanded into a sentence to justify it: Virtuali[s]ed Environment Neglected Operations Manipulation.
Very briefly put, it’s a “guest escape” bug in a popular open source codebase for products that provide what’s called virtualisation, a topic that comes up fairly often in any ongoing discussion of computer security.
Virtualisation is where you take one physical computer and make it pretend to be one or more pseudo-computers, known as virtual machines (VMs).
Inside those VMs, known as guests, you can then install a range of different operating systems and applications.
The physical computer, known as the host, acts as the overall manager of the virtual guests.
As we explained when we looked at a recent flaw in the well-known Xen virtualisation software, VMs are handy for many excellent reasons:
- For testing your software on multiple operating systems at the same time.
- For trying out new system configurations more conveniently than dedicating an entire server to each test.
- For investigating suspicious programs in a way that lets you efficiently watch what they do at a very low level.
- For sharing a huge and expensive server amongst multiple services or customers.
- For keeping spare capacity to run up an unknown number of extra server instances during busy times.
Each guest VM thinks it has a real computer all to itself, and, thanks to the virtualisation layer, can’t mess with any of the other guests.
That’s especially important in a hosting environment, where one physical server may provide virtual server instances to several different customers at the same time
For all you know, your competitor’s web portal might be running in a VM on the very same physical hardware as yours, if you both chose the same service provider.
And it’s equally important that no guest can “reach out” and fiddle with the real hardware on which the VM is running.
If a guest could make unregulated changes in another guest, or in the host itself (which controls all the other guests), that could cause a security crisis.
The VENOM problem
The VENOM bug was introduced more than a decade ago in open source software called QEMU (short for “quick emulator”), a groundbreaking project that spawned a number of commercialised virtualisation products that were derived from it.
These include KVM, Xen and VirtualBox.
Simply explained, there’s a buffer overflow in the software component that simulates floppy disk drives.
This means attackers inside any guest VM could, in theory, shovel both data and code of their own choosing out of the guest and into the memory space of the host operating system, where it might be possible to trick the host into running it.
That’s why we referred above to VENOM as a “guest escape.”
Guests aren’t supposed to be able to see or influence what’s going on in other guests, let alone on the host server, for obvious security reasons.
What to do?
If you use a virtualisation product that was derived from QEMU, check your vendor or distribution for a patch.
(VMWare and Microsoft Hyper-V are popular virtualisers that do not contain QEMU code, being independently-written proprietary products.)
You are probably thinking that very few VMs set up in the past few years will include simulated floppy drives, and that this should limit the reach of the bug.
→ I have lots of VMs for malware research, and only one of them includes a virtual floppy. That’s a DOS “PC” that I keep handy for demonstrating ancient floppy-borne malware. It doesn’t get many outings these days.
Unfortunately, according to SophosLabs, QEMU loads the buggy floppy controller code into memory even if you don’t set up a virtual floppy disk device.
So, by triggering the right system calls inside a VM, you can “tickle” the buggy code anyway, and potentially exploit the vulnerability.
According to CrowdStrike, the company that originally published details about VENOM, the same problem exists in Xen.
Even in VMs with no virtual floppy configured, Xen systems have the bug in memory, just as if you had a floppy controller card plugged into a real PC but no floppy disk attached to it.
One small saving grace about VENOM: an attacker who wants to exploit it must already have root (administrator) privileges in the guest operating system.
That’s cold comfort if you have a “naked” virtual server in a hosted server farm: you can give yourself root inside your own virtual server, and so can anyone else whose guest VM happens to be sharing the host with you at that moment.
But that’s usually not the case if you’re using a hosted software service – a content management system running on a hosted installation of WordPress, say, or a web server on a hosted version of Apache.
In that case, the service operator will be looking after the host server, the guest VMs and the software stack that underpins your data.
Neither you nor any other customer ought to have root privilege on the servers that manage your content. (And if an untrusted outsider did have root privilege, they would almost certainly be able to attack or steal your content anyway.)
Another saving grace that reduces the immediate alarm is that exploiting VENOM is not as simple as stuffing a memory buffer with executable code and waiting for it to run.
So, no in-the-wild exploits are currently known [2015-05-14T12:47Z].
The bottom line
• This is a serious vulnerability, but patches are readily available, so make sure you’ve applied them.
• Ask your cloud service providers if they use any affected products, and, if so, whether they’ve patched.
• Keep calm, and carry on with virtualisation – it’s too useful a tool to give up on.
NB. Sophos Cloud runs on AWS (Amazon Web Services). According to Amazon’s security bulletin on VENOM, “[t]here is no risk to AWS customer data or instances.”
Image of snake courtesy of Shutterstock.
10 comments on “The VENOM “virtual machine escape” bug – what you need to know”
It’s not completely accurate to assume that shared hosting services don’t give their clients root to their respective VMs. I host with DreamHost and have root on both of my VMs. It’s one of the major perks to having the VM as opposed to simply shared hosting. I can move files easily between users, perform advanced management, and it has enabled me to help a few customers clean out a site infection or two without having to possess/reset their user account (in fact, most of my customers don’t even have shell logins in the first place.)
I didn’t express myself as clearly as I might…in your example, I’d consider your VM to be what I referred to above as a “naked VM,” even if the OS and software stack inside your VM are provided (and even managed) for you by a hosting provider. *Your* customers, presumably, don’t have root access in the VM (modulo any other RCE/EoP holes in the software stack!), merely some sort of access via the software service you’re charging them for.
So although you might in theory be able to pwn your hosting provider by escaping from your VMs, *your* customers almost certainly could not use VENOM to break out of your software stack and then out of the VM, and thereby pwn both you and your hosting provider.
One more good reason to use virtualization is the much quicker ability to restore a system that has become compromised. That is assuming you do good, frequent backups, of course.
I run Windows 7 Pro and the only thing I use the VM for is a picture editing program that didn’t get upgraded when Windows 7 became available. I never link to the internet in the VM, but I still have IE which I obviously can’t delete.
The VM is also operating under XP which is no longer supported. I share picture files from Windows 7 to XP (the VM). Do I have to run a separate anti virus program and set up a separate firewall in the VM? I had been up until 2 days ago when some files from the VM got corrupted and I had to install it again.
I run anti-virus inside my VMs (Linux, Windows and OS X) and on my host (OS X). The reason is that while I’m inside the VM, I might as well be on another computer, so why wouldn’t I want to be independently protected?
My earnest recommendation is this: ditch XP; ditch the image editing program whose vendor hasn’t updated it for, what, a decade; and then you can ditch the VM and simplify your life.
We dont usually do product endorsements on Naked Security, but if you want an all-singing, all-dancing image editor for $0, try GIMP. A bit daunting at first, but stick with it and I suspect you won’t find anything it can’t do for you. And it’s under active development.
I’ll set up the antivirus and firewall again. And no, I’m not getting rid of XP or my VM. This editing program is superior to some of the more complicated ones. I’ve spent hundreds of dollars on trying to find something user friendly and I’ve yet to find one. I only wanted to confirm what I already knew. Thanks for your reply.
I use VMs – mostly to have some more obscure operating systems available if I need them, but I need to use Windows for one practical purpose. I was wondering why my host machine had updates to qemu-related packages yesterday. Now I know.
Yep, SophosLabs looked at those updates to check that they patch VENOM…and they do, so grab ’em while they’re hot 🙂
Paul, great article. I have been citing it all day and mis-attributing it to Graham Cluley. in my news reader, Naked Security is labeled “Graham Cluley|Naked Security.
William Hugh Murray, CISSP
Thanks for your kind words.
BTW, Graham left Sophos to strike out on his own a couple of years ago now:-)