Bigger than Heartbleed, 'Venom' security vulnerability threatens most datacenters

[RV_]

First the good news:

 

Excerpt:

 

"VMware, Microsoft Hyper-V, and Bochs hypervisors are not affected."

 

So many admins (not many here I know) can relax. Now for the rest:

 

Excerpt:

 

"Move over, Heartbleed. There's a new catastrophic vulnerability in town.

 

A security research firm is warning that a new bug could allow a hacker to take over vast portions of a datacenter -- from within.

The zero-day vulnerability lies in a legacy common component in widely-used virtualization software, allowing a hacker to infiltrate potentially every machine across a datacenter's network.

 

Most datacenters nowadays condense customers -- including major technology companies and smaller firms -- into virtualized machines, or multiple operating systems on one single server. Those virtualized systems are designed to share resources but remain as separate entities in the host hypervisor, which powers the virtual machines. A hacker can exploit this newly-discovered bug, known as "Venom" -- an acronym for "Virtualized Environment Neglected Operations Manipulation" -- to gain access to the entire hypervisor, as well as every network-connected device in that datacenter.

 

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 bug, found in open-source computer emulator QEMU, dates back to 2004. Many modern virtualization platforms, including Xen, KVM, and Oracle's VirtualBox, include the buggy code.

 

"Millions of virtual machines are using one of these vulnerable platforms," said CrowdStrike's Jason Geffner, the researcher who found the bug, in a phone interview Tuesday.

 

The flaw may be one of the biggest vulnerabilities found this year. It comes just over a year after the notorious Heartbleed bug, which allowed malicious actors to grab data from the memory of servers running affected versions of the open-source OpenSSL encryption software.

 

"Heartbleed lets an adversary look through the window of a house and gather information based on what they see," said Geffner, using an analogy. "Venom allows a person to break in to a house, but also every other house in the neighborhood as well."

 

Geffner said that the company worked with software makers to help patch the bug before it was publicly disclosed Wednesday. As many companies offer their own hardware and software, patches can be applied to thousands of affected customers without any downtime.

 

Now, he said, the big concern is companies that run systems that can't be automatically patched.

 

To take advantage of the flaw, a hacker would have to gain access to a virtual machine with high or "root" privileges of the system. Geffner warned that it would take little effort to rent a virtual machine from a cloud computing service to exploit the hypervisor from there.

 

A spokesperson for Oracle declined to comment.

 

A spokesperson for The Linux Foundation, which runs the Xen Project, declined to comment on specifics, but noted that a security advisory was published."

 

There is more tech details in the article here: http://www.zdnet.com/article/venom-security-flaw-millions-of-virtual-machines-datacenters/?tag=nl.e539&s_cid=e539&ttag=e539&ftag=TRE17cfd61

 

As well before it is called FUD or click bait, or the erroneous we turned the floppy controller off or did not include it read all the comments at the bottom. If the floppy controller code was not patched, activated or not, the vulnerability is still present, and the whole system will still be vulnerable until patched.

[wa_desert_rat]

Nope, not FUD. But only applicable to those who run a data center focused on multiple VMs hosted on blade servers. I don't know what VM AWS uses (Amazon Web Services) but their cloud is jammed with hackers (if click-bot activity is any indication). I no longer run any kind of a data center (and the one I did run was tiny even back then). This might affect Gmail users if Google uses open an open source virtual hypervisor.

 

Although, if I did run a big data center it would be on VMWare which is immune to this exploit (and also immune to the AlienSpy RAT even if it did work on Linux (which no one has yet managed to demonstrate despite me asking them weeks ago). (In fact, just making your *nix system *appear* to be using VMWare would stop it!). (Which is why I've added a couple lines to my /etc directories on all the systems I admin... I mean, what can it hurt?)

 

But with so many people using the "cloud" now and given the fact that not many of them know exactly what "cloud" configuration they're leaving all their data on, it's probably a good idea not to be complacent.

 

These things are always interesting. Nice post.

 

 

WDR

[skp51443]

A very interesting attack as it can escape the virtual machine and attack the host machine but it is very limited in just what can be attacked and what access you need to make the attack work. Unless you are a user of one of the unpatched services or run your own unpatched virtual machine it isn't an issue for you.

 

http://www.theregister.co.uk/2015/05/14/venom_analysis

 

 

“In order to exploit this vulnerability, an attacker would require access to an existing virtual machine,” Sigler said. “In other words, this attack can’t be pulled off remotely. Most corporate virtual environments are isolated from anonymous or public access and would be immune to attack. In this regard the attack is very similar to a Privilege Escalation attack, where the attacker requires an initial foothold before exploitation.”

“I would see this attack typically used to target hosting companies that use virtual environments like KVM. An attacker would purchase a KVM instance then use VENOM to breach the hosting machine,” he added.

Tod Beardsley, research manager at Rapid7, the firm that markets the Metasploit penetration testing tool, added: “The people most affected by VENOM are those who run hosted VPS services (and therefore, do routinely give root access to strangers' guest machines), and those who subscribe to the same VPS [virtual private server] services. Customers of VPS services should pester their vendors until patches are applied, and the vendors should move on this rapidly."

"It's important to note that while this vulnerability is technically local-only, successful exploitation leads to breaking out of a guest OS to the host OS. This circumstance leads me to believe that VENOM is an 'interesting' bug to the sorts of people who do exploit research for a living. To be able to break out of a guest OS to a host OS is a rare and powerful ability, and such bugs are uncommon," Beardsley added.

 

 

“While CVE 2015-3456 (VENOM) does exist in the default configuration and does allow arbitrary code execution, it only impacts three of the six major vendors – and two of those are already patched,"

[RV_]

For Venom security flaw, the fix is in: Patch your VM today

Excerpt:

"A successful attack still wouldn't be easy. It requires a user to have administrative or root access to the VM. But, CrowdStrike claims that with Venom, attackers can jump from one VM to another. So, in theory, a single insecure VM could be used to successfully assault other VMs or the underlying operating system.

True, there are no known exploits... yet. But, Venom is a simple memory buffer overflow hole. It can be exploited on any operating system, which supports QEMU virtualization or hypervisors. That includes, Linux, Mac OS X, Solaris, and Windows. In short, writing an exploit is trivial. This makes Venom a serious security problem that must be addressed. You can't walk it off.

Fortunately, the fixes are in.
The QEMU fix itself is now available in source code. Red Hat has been working on the fix since last week.

Xen, noting that any Xen system running x86 VMs are vulnerable, has released fixes for Xen 4.2.x and later. If you're using an earlier version of Xen, upgrade and apply the patch.

VM hypervisors that aren't based on QEMU, such as VMware, Microsoft Hyper-V, and Bochs hypervisors, are immune to Venom attacks.

All versions of Red Hat Enterprise Linux (RHEL), which includes QEMU, could be attacked. Red Hat recommend that administrators update their system using the commands, "yum update" or "yum update qemu-kvm." Once this is done, you must "power off" all VM guests for the update to take place. Restarting the guest operating system is not enough because it would still use the old QEMU binary.

Anyone running a Linux server with QEMU installed should follow Red Hat's general instructions. For example, on Debian and Ubuntu, update your system with the following commands:
sudo apt-get clean
sudo apt-get update
sudo apt-get upgrade
power off your VMs, restart them, and you'll be safe.

SUSE Linux is also vulnerable, but the SUSE Cloud is not. While SUSE is still prepping its Venom fix, the company recommends that you can work around the problem on SUSE Linux Enterprise Server (SLES) 11 and 12 by managing your VMs with libvirt. This VM toolkit supports KVM/QEMU, Xen, and Virtualbox. It protects you from Venom by automatically starting VMs with "nodefaults," which means QEMU-based VMs shouldn't have access to the bad code.

 

Oracle has yet to release a fix for VirtualBox. Oracle software lead Frank Mehnert told ZDNet, "We will release a VirtualBox 4.3 maintenance release very soon."

 

So, by promptly patching your system and then turning off and on your VMs, you should be safe. So, do it now, don't wait for some sidewinder of a hacker to come up with an exploit and bite you."

http://www.rvnetwork.com/index.php?showtopic=117818#entry776494

 

Stan,

Some additional quotes from your article:

 

"Analysis A newly discovered vulnerability in many popular virtual machine platforms is serious, but nowhere near as bad as last year’s Heartbleed vulnerability, according to security experts.

 

“I would see this attack typically used to target hosting companies that use virtual environments like KVM. An attacker would purchase a KVM instance then use VENOM to breach the hosting machine,” he added.

 

"It's important to note that while this vulnerability is technically local-only, successful exploitation leads to breaking out of a guest OS to the host OS. This circumstance leads me to believe that VENOM is an 'interesting' bug to the sorts of people who do exploit research for a living. To be able to break out of a guest OS to a host OS is a rare and powerful ability, and such bugs are uncommon," Beardsley added."

 

Same article link, different choices to excerpt: http://www.theregister.co.uk/2015/05/14/venom_analysis

 

It is serious, according to The Register yesterday. Today the patch is out.

[skp51443]

So how many of us here are running one of the vulnerable hyper-visors either locally or on a rented remote machine?

 

Of the ones that are how many have your hypervisor set up to support virtual floppy disks making the attack possible?

 

OK, you folks need to worry about this one if your daily automatic check for security updates hasn't already picked up the fix.

 

 

For the folks that are interested in reading about bugs it is an interesting topic.

 

For the rest of us it isn't an issue.

[wa_desert_rat]

Well more stuff coming down the pike about VENOM; mostly asserting that comparing it to HEARTBLEED is just a way to gain headlines. It turns out that AWS is unaffected and, as far as I'm concerned, if any VM system would be the most likely to be taken down it would be AWS if only because it is trivially easy to gain an AWS account and time on the server is free for admins who are experimenting. At least it's trivial for most engineers and admins; I set one up last year just to see if one of my clients would find it more economical than to use an on-site Linux server (it wasn't).

 

Nothing found "in the wild" as yet and there was plenty of time before the "announcement" for patches and updates.

 

Here is the latest I've seen: http://www.csoonline.com/article/2922066/vulnerabilities/venom-hype-and-pre-planned-marketing-campaign-panned-by-experts.html

 

Even so, this is a pretty interesting deep-code vulnerability and if it could be exploited remotely (using Java or something) then it could conceivably become a serious issue given the numbers of organizations using VM now.

 

WDR

[skp51443]

WDR, I'm sure the researchers are going bonkers over this one, the ability to break out of the VM and attack the host system or other VMs is very worrying. If it wasn't found in such a rarely used portion of the code it could have been a big deal thus justifying some of the initial headlines.

 

I'm guessing this is getting talked about at the Linux Foundation level and may get another block of code moved to their intensive care effort. It is good to see folks taking the time to poke into the darker, lesser used corners of the Linux system and discover this type of thing.

 

The press is painting themselves into the same corner as "the little boy who cried wolf" with the continuing click-bait articles that need later clarification or correction. It is going to hurt them in the long run as folks realize what is being done and tune the sources of worthless noise out. I know I have stopped following several places that have stopped being reliable and worth subscribing to for just that reason.

[wa_desert_rat]

 

The press is painting themselves into the same corner as "the little boy who cried wolf" with the continuing click-bait articles that need later clarification or correction. It is going to hurt them in the long run as folks realize what is being done and tune the sources of worthless noise out. I know I have stopped following several places that have stopped being reliable and worth subscribing to for just that reason.

Credibility of some sites among professional IT people is something of an issue. ZDnet is one I stopped following years back. Just their methodology of trying to move users who want to download one product into downloading another - unwanted and potentially harmful - product all by itself should be a red flag. They're hardly alone in this but it's still a nasty practice that leaves a bad aftertaste.

 

Now that developers are offering monetary rewards for exploit reports (instead of trying to cover them up) the focus among white-hats has shifted away from looking for the issues in open-source (where the only reward might be name recognition amongst a pretty tiny cadre of coders).

 

This was a particularly interesting exploit because simply not enabling the virtual floppy would not disable the exploit. It wasn't part of a module that an admin could remove easily, either. It was part of the hypervisor code itself. So esoteric that no one had even found it before (and I suspect that any admin would immediately notice if it had been used). Gotta applaud that kind of effort.

 

WDR