Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


08:01 AM
Connect Directly

VENOM Zero-Day May Affect Thousands Of Cloud, Virtualization Products

Critical vulnerability in the open-source QEMU hypervisor lets attackers break out of a virtual machine, execute code on a host machine and access all the other VMs on the host.

A zero-day vulnerability affecting a variety of virtualization platforms and cloud services allows attackers to break out of a virtual machine (VM), execute code on the host machine and access any other VMs running on it, CrowdStrike researchers revealed today.

"The good feeling is that we discovered this before the bad guys did," says CrowdStrike senior security researcher Jason Geffner, who found the bug, which CrowdStrike dubbed the vulnerability Virtualized Environment Neglected Operations Manipulation (VENOM).

The vulnerability is in the virtual floppy disk controller of Quick Emulator (QEMU), a free, open-source hypervisor. It's another example of little-used, but on-by-default legacy code (like a floppy disk controller) being manipulated for malicious use -- hence the word "neglected" in the name.

Some of QEMU's code, including the vulnerable bit, has been used by other virtualization platforms, like the popular Xen and Kernel-based Virtual Machine (KVM), which are often used in infrastructure-as-a-service, and Oracle VM VirtualBox, which is commonly used in test-dev environments. So hundreds or thousands of products that use virtualization technology -- on servers, clients, appliances, and in the cloud -- are vulnerable to VENOM. Since most hypervisors run with root access to the host machine, the potential damage is severe.

This is precisely the kind of nightmare scenario that has caused some organizations to avoid the cloud and virtualization altogether -- putting all your corporate eggs in one questionably secure basket and perhaps sharing server space with a cybercriminal.

For that reason, CrowdStrike has declared VENOM a critical vulnerability. The company has worked with QEMU -- and through them, with other affected vendors -- on a coordinated patch release. CrowdStrike CTO and co-founder Dmitri Alperovitch stresses that organizations should check with their cloud providers to ensure they have already issued the patch, and to patch their own on-premise applications and appliances immediately.

"Obviously it's a great risk for on-premise," says Geffner, "because usually it takes months" for companies to completely remediate vulnerabilities.

Although VENOM may legitimize concerns about attackers busting out of a public cloud instance and accessing other customers' cloud instances, the coordinated patch release today legitimizes some cloud vendors' assertion that they can do a more efficient job on security than individual organizations.  

Either way, says Geffner, organizations still weighing their options, "can take solace from the fact these kind of security findings are extremely rare ... and not this broadly scoped."

Like Heartbleed and ShellShock before it, VENOM is a severe, wide-ranging vulnerability in an open-source tool... but worse, according to the researchers.

As Alperovitch describes it: Heartbleed would let an attacker look through the windows of your house; Shellshock would let them inside your house; VENOM gives them complete access to everything in your house, including all your locked-up valuables, and, Geffner says, "an underground tunnel in which [they] can access all your neighbors' houses."

Vulnerabilities like VENOM may renew some fears about cloud security, but that doesn't mean it will slow cloud adoption.

"Everything is moving to the cloud," says Dan Kaminsky, chief scientist at White Ops, who collaborated with CrowdStrike on VENOM, says. "Even Zynga is shutting down their $100 million data center because it's better to deploy in minutes than months."

"There is a cost to this move [to the cloud]," he says, "which is that attackers who once needed to find an exploit may get some degree of local privilege using money. There's a lot riding on the code that isolates VMs, but like all code there's a risk of bugs. Many cloud providers offer enhanced isolation of hardware, such that at minimum you're only exposed to other VM's from your own organization. When feasible it's worth outbidding attackers to acquire this isolation."

For more information about VENOM, see http://venom.crowdstrike.com.

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
5/15/2015 | 9:28:37 AM
Re: Good Research Bad Media Reaction
@ kenwestin ... You said... "I do believe that some of the media surrounding this vulnerability has been a bit overblown, some stating that this vulnerability is has broken cloud security and millions of systems are in danger of being immediately hacked."

I think what is overblown is how everyone wants to compare one vulnerability to the other; I personally think that is dangerous. Why, because no two vulnerabilities are the same there is no way that you can compare this vulnerability to Heartbleed or to a vulnerability like BEAST. With Heartbleed it was pretty easy to say how big this would be because there was no denying it. With this particular vulnerability, it does confirm an argument that has been going on for a very long time that quite a few folks said could not happen. And this, as with Heartbleed has internal implications too if these affected systems are used inhouse.  And while this particular bug has not impacted all of the virtual space... I can bet you the rest are scrambling to make sure it doesn't affect them too. Remember, when Heartbleed was first reported nobody took as seriously as they did when the scope was finally realized.

"High impact vulnerabilities are becoming the new normal, some security analysts expecting us to see one big one per quarter. The industry as a whole needs to work on how to best address these vulnerabilities without overhyping them..."

Now this I can totally agree with, but my one bit of advice would be to assume that every vulnerability has the ability to disrupt your operations or possible damage your reputation.

Question, which was worse:

a)      Blaster

b)      SQL Slammer
User Rank: Apprentice
5/14/2015 | 6:31:46 PM
So, why is your disk floppy?
OK, we have a vlun - surprise.

But it's in a component that maybe 50% of us have never touched, much less know about.

And where's the next one coming from - the joystick interface?  the UV-EEPROM programmer?

I'm not surprised stuff shows up in negelceted interfaces but the thing that surprises me is why a bright shiny VM should have a floppy interface component at all.  Are people looking at the stuff that's added into a VM build and being sure it's necessary?

Hard drive interface - check

Video interface - check

Keyboard interface - check

Mouse interface - check

Serial port interface - check

Parallel port interface - check - uh - what's a parallel port?

Tin hat interface protection - check

Rubber band motor back up interface - check

And so it goes - the path to h#$l is paved with ignorance and obsolete interfaces.

User Rank: Ninja
5/14/2015 | 5:22:39 PM
Re: Re-thinking VM Deployement
... and the problem with vulnerabilities is what... they do not go away!  Because there will always be a management\admin team somewhere that doesn't get it... try to skate on that thin ice for as long as possible or not willing to spend what it takes to fix it.

And you're correct about the PCI Council, so in my opinion, (which I'm pretty sure they care nothing about) this vulnerability confirms what security folks have been saying for years, that this is possible and hopefully forces the PCI Council to do the right thing... but you can probably hear the crocodile tears hitting the floor already from the large vendors asking for exceptions and grandfather (not Santa) clauses.
Sara Peters
Sara Peters,
User Rank: Author
5/14/2015 | 5:13:32 PM
Re: Re-thinking VM Deployement
@ODA155  Good point! That's been the question about virtualization forever, and the PCI Council was hesitant to make a ruling on it in the beginning. That said... ultimately, Venom is just a vulnerability. Until this, or a similar vuln, gets exploited in any significant fashion, I doubt the regulators would make any changes.
User Rank: Ninja
5/14/2015 | 4:27:22 PM
Re-thinking VM Deployement
So I aked this question internally just to speark discussion, so now I'll ask it here...

"If this is in fact a possibility then this would be a game-changer, especially in how organizations plan or decide what VM's reside on a specific host, such as can\should a VM subject to PCI or HIPAA be hosted on the same platform as non PCI or VM's. If so, do\should the non compliance required VM's have to me those compliance standards?"
User Rank: Apprentice
5/13/2015 | 4:41:57 PM
Good Research Bad Media Reaction
The research on this particular vulnerability is excellent,  Jason Geffner and the folks who researched and are patching this should be commended. However, I do believe that some of the media surrounding this vulnerability has been a bit overblown, some stating that this vulnerability is has broken cloud security and millions of systems are in danger of being immediately hacked.

However, the actual impact is nowhere near a doomsday scenario, or the same level of  Heartbleed to which this is being compared to in the media. This vulnerability did not affect Amazon AWS, Linode or a any other number of cloud service providers. There are also a number of factors that have to be in place for the vulnerability to pose an actual risk. 

High impact vulnerabilities are becoming the new normal, some security analysts expecting us to see one big one per quarter. The industry as a whole needs to work on how to best address these vulnerabilities without overhyping them, or we are going to run into a boy who cried wolf scenario and businesses and security leaders will become numb to the next real threat they need to patch in their environment. 
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...