Venom – A security vulnerability in virtual floppy drive code

http://venom.crowdstrike.com/

by fulafel • 11 years ago

236 118 11 years ago

venom.crowdstrike.com

fulafel• 11 years ago

From Q&A:

"Q: How is this different from previous VM escape vulnerabilities?

A: Most VM escape vulnerabilities discovered in the past were only exploitable in non-default configurations or in configurations that wouldn’t be used in secured environments. Other VM escape vulnerabilities only applied to a single virtualization platform, or didn’t directly allow for arbitrary code execution."

Edit: Xen advisory: http://xenbits.xen.org/xsa/advisory-133.html

brohee2• 11 years ago

Amazon states that AWS is not vulnerable, no details but presumably they patched before the public disclosure.

https://aws.amazon.com/security/security-bulletins/XSA_Secur...

sneak7• 11 years ago

We're all equal, but some are more equal than others.

This is the endgame of your so-called "responsible disclosure". Those with profit loss exposure win, and the peasants get it whenever the PR company is done making the logo and infographics.

ihsw• 11 years ago

It is a necessary evil, no need for the rhetoric.

Profit and PR are hardly the goal here -- community awareness and public safety are paramount. Vulnerabilities need to be obviated to the general populace at large.

Anderkent• 11 years ago

How is it bad that large providers have an opportunity to patch before the vulnerability is released to the wild?

Maybe next you'll insist that everyone's prevented from patching for a week after disclosure so that smaller companies that don't have the resources to react immediately are not unfairly left behind?

duaneb2• 11 years ago

And the alternative?

cthalupa3• 11 years ago

You do not have to be a large company to get on the Xen pre-disclosure list.

http://www.xenproject.org/security-policy.html

----------

Public hosting providers;

Large-scale organisational users of Xen;

Vendors of Xen-based systems;

Distributors of operating systems with Xen support.

Here "provider", "vendor", and "distributor" is meant to include anyone who is making a genuine service, available to the public, whether for a fee or gratis. For projects providing a service for a fee, the rule of thumb of "genuine" is that you are offering services which people are purchasing. For gratis projects, the rule of thumb for "genuine" is measured in terms of the amount of time committed to providing the service. For instance, a software project which has 2-3 active developers, each of whom spend 3-4 hours per week doing development, is very likely to be accepted; whereas a project with a single developer who spends a few hours a month will most likey be rejected.

----------

Basically, if you provide a service to the public which uses Xen (Not restricted on size), or use Xen at large scale internally, you can get on the list. There are several small hosting providers that utilize Xen on that list.

Presumably if you use Xen at small scale internally you're less worried about security vulnerabilities as it is only your employees with root access to the machines - if external users have root access, you probably fall under one of the other definitions.

oasisbob• 11 years ago

Or, AWS takes steps to mitigate their exposure, regardless of whether or not they receive embargoed disclosures.

On the Rackspace public cloud I've been through three full-fleet reboot cycles so far. Only one of those affected AWS customers, and AWS handled it in such a way that only a portion of their fleet was affected.

How could AWS do this when Rackspace and others couldn't?

For one, they could stratify guest placement based on instance type and guest OS. (Which I hear they do.) Most recent XSAs have only affected PV or HVM guests, not both. If you keep PV and HVM guests separate ...

AWS seems to be an example of good engineering, not an example of the perils of capitalism.

jeswin• 11 years ago

It would have been reassuring if they disclosed whether they were vulnerable earlier, and if it required a patch to be installed.

rlpb2• 11 years ago

The vulnerability is in floppy drive emulator code. It isn't clear to me whether all users are vulnerable or only hosts that have floppy drive devices defined [in their guests] are vulnerable.

If the latter, perhaps Amazon was never vulnerable anyway?

mhayden• 11 years ago

The exploit affects VM's whether or not they have a floppy controller or disk attached.

brohee2• 11 years ago

The disclosure states that due to another bug, even floppy less hosts were vulnerable...

cesarb• 11 years ago

Or perhaps they're using a custom-compiled Xen without the vulnerable floppy disk emulation.

drzaiusapelord3• 11 years ago

I'm guessing this. Why even make floppy emulation available? It has no use cases on AWS. Floppy support only exists really for Windows driver install at install time, if you can't slipstream the driver in. They probably tore out a lot of stuff while developing the EC2 infrastructure.

tgeek• 11 years ago

More likely this. AWS has at numerous talks mentioned a slightly franken-xen fork of Xen.

jsabo2• 11 years ago

As other people mentioned, it seems more likely that they're running a Xen fork or have some other mitigation. The redhat notes state that once the host is patched, the VMs need to be shut down for it to take effect: https://rhn.redhat.com/errata/RHSA-2015-0998.html

mariusz79• 11 years ago

"You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit."

The rest of the rant is here:

http://www.electricmonk.nl/log/2007/10/25/virtualization-sec...

agentultra• 11 years ago

From the same article:

Theo de Raadt's problem is that he views security the way cryptography experts view cyphers: as an absolute. But security isn't like math. It's not absolute. There are right and wrong ways of doing security.

Not an absolute but there is a right and wrong way to "do security?"

To be fair Boender is attacking the naive maxim that "virtualization is secure." It's just another layer if you isolate processes inside of virtualized run-time environments. Makes sense... it's not snake oil.

However there is no need for "right" and "wrong" in these discussions. The security of any given system exists in a continuum and it will only be a matter of time before the next vulnerability is discovered. I get the sense that all we can do is limit the damage that can be done by any particular system.

It seems that virtualization is just one path towards providing those limits just as chroot and other attempts have been.

I'm most interested in seeing how jitsu and unikernels can turn the tables... not only can a process be wrapped in a virtualization layer but it is short lived and only runs when it is requested. It puts the onus on us to set up the summoner properly and provide safe-guards... but it's just another layer of complexity for attackers to manage.

avsm• 11 years ago

I'm most interested in seeing how jitsu and unikernels can turn the tables

The useful aspect about the MirageOS unikernels is that they use the pure Xen PV interface, which has almost no dependency on qemu. No floppy or block/net emulation, timers through the direct Xen shared_info page, and generally as "native" to x86 as Xen permits.

krakensden• 11 years ago

Isn't that the appeal of KVM, though? It's just the Linux kernel, instead of a new thing like Xen?

csirac22• 11 years ago

It's with those thoughts in mind that usually deploy Xen dom0s without QEMU installed at all (so only PV guests). You just have to read through past Xen CVEs to see that HVM presents a lot of attack surface, admittedly I'm unsure if PV is smaller but shallower (certainly you leak more info about dom0 to guests but for guest escapes it seems there are just a lot of opportunities with QEMU in the mix).

specto• 11 years ago

Venom... really... ugh

jessaustin• 11 years ago

Where's G.I. Joe when we need him?

rlpb2• 11 years ago

Since the vulnerability is in floppy drive emulator code, it isn't clear to me whether all deployments are vulnerable or only hosts that have floppy drive devices defined in their guests are vulnerable. Can someone please clarify?

corv• 11 years ago

"For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers."

mcintyre1994• 11 years ago

From the FAQ:

For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

So I guess for KVM you're safe if you don't have a virtual floppy drive, unclear whether it's KVM default though. For the others, you're still vulnerable by an unrelated bug.

rwmj4• 11 years ago

A simpler, less breathless description from the Red Hat BZ[1]

An out-of-bounds memory access flaw was found in the way QEMU's virtual Floppy Disk Controller (FDC) handled FIFO buffer access while processing certain FDC commands. A privileged guest user could use this flaw to crash the guest or, potentially, execute arbitrary code on the host with the privileges of the hosting QEMU process.

If you're using RHEL, then SELinux further confines the qemu process so although you can run arbitrary code in there (which is very bad) you cannot access any files on the host filesystem except ones which qemu has open. Also libvirt runs qemu as a separate user, and further confines it with some cgroups rules. Depending on the version of RHEL, seccomp may be involved too, which limits the type of syscalls that qemu can make.

Applying the qemu fix is still highly recommended of course.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1218611

drzaiusapelord3• 11 years ago

Floppy Disk Controller (FDC)

Why isn't legacy junk like this disabled by default? How many people need a floppy disk controller?

There's something scary about how legacy compatible a lot of FOSS projects are. It just raises the attack surface and leads to stuff like this.

dsr_• 11 years ago

The article says that even if you turned off the option, Xen and QEMU have a bug which doesn't actually do that.

Arguing about defaults requires a step back to policy level, which is something for which many projects have trouble finding time and attention.

rwmj4• 11 years ago

Why indeed. In fact we tried to remove the FDC, but Windows needs it in order to do certain operations like installing some drivers, so there was resistance there.

Anyhow, security bugs happen (in all sorts of devices, old and new), and the important thing is that we fix them quickly and that SELinux mitigates the immediate effects.

stephengillie2• 11 years ago

This is one of my biggest rants as a VMWare admin. Every VM I build, I have to boot to BIOS and disable the drive there. Why is it even enabled? Do VM manufacturers have a large number of government or corporate customers for whom a floppy interface is necessary? I haven't had to use them in almost 10 years; even RAID drivers are downloadable for easy use with any CD or USB drive, and even slipstreamed into the OS install.

Unfortunately I'm always working with established systems, so I can't push this feedback during the sales process.

userbinator2• 11 years ago

Don't forget that Heartbleed was in a new feature of TLS... legacy or not doesn't matter. If anything I'd say that older code tends to mature and stabilise over time as bug fixes are applied - it's the "rip everything out and rewrite it" mentality that leads to more bugs.

lbotos• 11 years ago

This is why I personally think unikernels and their ilk will be the next big thing. Sure, bugs and vulns will exist, but a lot will also be removed.

mjgoins• 11 years ago

This isn't a justification, but I've had to use the virtual floppy drive as recently as this year, to install drivers on proprietary OSes under virtualization.

yellowapple3• 11 years ago

How many people need a floppy disk controller?

Raises hand

userbinator2• 11 years ago

An even simpler description of the root cause: a circular buffer used as a FIFO was not treated as being circular - the modulus operation for indices was omitted, allowing them to run off the end and not wrap back to the beginning as they should.

StavrosK• 11 years ago

I think my new hobby is to go around vulnerability threads and ask whether they'd be possible if the thing was written in Rust, and tally the results.

I haven't even especially tried Rust, but I think it's time for a safer language/compiler.

zurn2• 11 years ago

Well, this lets the attacker jump to neighbouring VMs. So unless there's some extra SELinux magic going on, the protections get you so far as "OK only all my virtual machines are compromised" which is very small consolation for a lot of setups. (And complete host compromise if it happens to be bad week re local kernel privilege escalation bugs.)

rwmj4• 11 years ago

You are wrong. SELinux does protect adjacent VMs, by putting each VM into its own separate context and controlling which host files/devices are assigned to each context label. VMs cannot access files or devices on the host which are assigned to other VMs.

That is the purpose of the cXXX,cYYY part of the label as seen in the example here:

https://fedoraproject.org/wiki/Features/SVirt_Mandatory_Acce...

Eridrus• 11 years ago

If you're using RHEL, then SELinux further confines the qemu process so although you can run arbitrary code in there (which is very bad) you cannot access any files on the host filesystem except ones which qemu has open.

So, what you're saying is you don't expect attackers who can write exploits to escape a VM to be able to write a linux privilege escalation exploit when SELinux is enabled?

csirac22• 11 years ago

It's why I try to deploy xen dom0s without any QEMU installed at all; reading through past xen CVEs was enough to convince me that HVM guests seem more exposed.. If anybody knows a writeup on what you might lose in terms of isolation and protection from guest escapes by sticking to PV, please do share

cjhanks• 11 years ago

Paravirtualization loses instructions which are useful for high performance computing. That's not relevant to isolation/protection... but it is worth mentioning.

gvb• 11 years ago

[...] security vulnerability in the virtual floppy drive code [...] For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default.

That is a pretty simple mitigation. Make sure there are no (unnecessary) virtual floppy devices defined in your VMs.

I checked my VMs (Ubuntu/KVM) and, as expected, none of them have a virtual floppy - they are not added by default on that platform.

muppetman• 11 years ago

You didn't read much of the page :)

To quote:

bonzini3• 11 years ago

They don't have a virtual floppy drive, but they do have a virtual floppy drive _controller_.

orf• 11 years ago

I don't like this trend of "marketing vulnerabilities" with a cute name and a startup-looking landing page. That entire page says nothing about the actual issue, the nice looking graphic just shows how this exploit (and really any exploit like this?) can give attackers access to things outside of a VM. Duh.

dantillberg• 11 years ago

It makes sense for the ones that require mass mobilization and mass education to fix. This vulnerability isn't quite that... there are relatively fewer people managing VM infrastructure, and this only affects certain types of VMs.

That said, it's really hard to market security companies in ways that represent the hard work that they do, in ways that are not all snake oil and spin. So it's hard to blame folks for trying to turn excellent security investigative work into self-promotional opportunities.

(Edits: clarity and trying not to sound judgmental of the parent comment)

dmix• 11 years ago

require mass mobilization and mass education to fix

Except that Crowdstrike is heavily involved in 'threat intelligence' so this isn't really about patching vulnerabilities at the technical level but educating non-technical executives on threats and 'threat actors'. So corporate execs can be handed a dossier of recent events, like they were the US President evaluating their national security policy.

The only problem is that threat intelligence has marginal value, as infosec changes so rapidly and is so diverse, so at the end of the day it is very much simply emotional gratification - that Crowdstrike delivers at a very high price.

In terms of resource utilization, it doesn't seem like a good use of time/money to obsess over each bug as if it were an atypical event in a slow moving enviornment. But hey if it gets a few people at the top to start caring about security, maybe there is some value... I just hope it doesn't result in execs nagging the infosec team for updates on 'venom' and disrupting their work on real security measures for the company by focusing on the latest hot topic.

butwhy• 11 years ago

Why don't you like this trend? I don't see the harm.

Also, the FAQ explains a lot; including the details of how the vulnerability works.

nkassis• 11 years ago

Personally I feel that the presentation seems a bit inefficient. Lot's of extra graphics instead of putting up more important information up front.

The added design here seems a waste of effort and not really adapted to the targeted audience.

EDIT: The xen advisory gives you all the info you need in a couple of block of text: http://xenbits.xen.org/xsa/advisory-133.html

yellowapple3• 11 years ago

It means that folks with little to no technical experience (read: authors of WiReD articles) will latch onto the new buzzword and start regurgitating it left and right, eventually tricking other technologically-illiterate people to latch onto it and start pelting me with questions like "OMG DID YOU HEAR ABOUT VENOM???!!!" and "OMG U BUTTR PASH UR SURVURZ OMGOMGLOL!!!!111one" instead of letting me do my job. All because the publishers want to satisfy their attention-seeking desires ("LOOK AT ME I FOUND A SECURITY BUG AND GAVE IT A HIP COOL BUZZWORD I'M SO SPECIAL!!!!").

I personally don't like the trend for the same reason why I dislike terminology like "ninja" or "rockstar" or "badass" or "devops". It cheapens computer science/engineering into resembling something a bunch of hip middle schoolers yammer on about alongside their video games and their skateboards instead of the multi-billion-dollar professional field it actually is.

lloeki• 11 years ago

I see a benefit outside tech circles: I can readily share such a nice presentation form factor to explain to upper management why security and best practices matter. Later on, instead of important issues being hand-waved at meetings, proper steps will be taken care of with management approval.

Please don't underestimate the human work needed to be done along with our tech jobs.

mattkrea• 11 years ago

A thousand times this.

So many times have I tried to push things forward (internal system upgrades, new security policies, etc) that did not have any immediate impact but then something happens and we have to scramble together.

Being able to show this to a non-technical person and have them at least somewhat understand that there is a problem that needs to be addressed is invaluable.

sneak7• 11 years ago

Nobody does, really, but it turns out that we are all playing a marketing game every second of our lives. Some of us just don't realize it.

You can play, or you can abstain, but you can't abstain from the effects of abstaining (to paraphrase Rand).

zurn2• 11 years ago

It does explain the FDC IO port buffer overrun under the Q&A heading "What is the vulnerability?"

What "the actual issue" is depends on your POV.One might argue the big-picture view given in the infographic is closer to providing a workable description of the problem for most people than the bit-twiddly details.

vinhboy• 11 years ago

I like it. I found the site pretty informative from a layman standpoint. I find the whole marketing of vulnerabilities pretty fun. It's like the ASCII art and MIDI in those keygen software.

rmetzler• 11 years ago

I like to have a name to refer to, instead of "you know this vulnerability CVE-2015-xxxx affecting this software we use on some machines in some of our data centers".

I find it much easier to talk about heartbleed or shellshock (which is like ~7 different bugs). But googling for bugs and to find out which versions/patches fix this bug, I'll still need the CVE number.

alricb• 11 years ago

The missing reset of the fifo is in one of the handlers defined at http://git.qemu.org/?p=qemu.git;a=blob;f=hw/block/fdc.c;hb=2...

fdctrl_stop_transfer() might be one of the incriminated functions.

thrownaway24242• 11 years ago

I like how I had to read 100 comments on Hacker News to learn this information. Vulnerability disclosure just isn't what it used to be.

LnxPrgr3• 11 years ago

A shame, too, because there's a (small, admittedly) lesson buried in the fix--one that can be applied even in low-level languages.

If you have a buffer with odd semantics (such as wrapping out-of-bounds addresses back into bounds), it should probably be wrapped in something that enforces that. In C++, it could be made to look like a normal buffer, except that operator[] is overloaded to wrap for you, and you can make the compiler scream at you if you try to escape that safety net--for an inline class, very likely without any performance cost over adding the wrapping computation to each access by hand.

In C, your options are more limited. The safest is an opaque handle that has to be passed to an accessor function. You're more likely to take a performance hit (unless LTO fixes it for you), but in a floppy drive emulator, I doubt it matters.

If the overhead does matter, a macro or static inline function still makes the access convention easier to memorize, which should make it less likely for someone to forget, and should make code that does forget more suspicious on code review.

breakingcups• 11 years ago

The diff is literaly linked in the article.

rolandr• 11 years ago

Given the complexity of QEMU and its pace of development, there is likely an endless supply of such bugs for punching through the QEMU emulation layer. The problem is that most of the time, the QEMU process is running in dom0, giving an attacker an opportunity to hijack the hypervisor. Xen offers a more general solution for this: running QEMU in a stub domain. The main problem with that solution right now is that Xen forked QEMU such that the stub domain only supports running QEMU 0.10 or such - the up-to-date version of QEMU (known in Xen as qemu-upstream) is somewhere around 2.2, but it runs the emulation layer as a process in dom0, which exposes the system as a whole to "VENOM" and related attacks on QEMU.

justincormack2• 11 years ago

I know there are people at Xen working on getting upstream qemu working in a stub domain. Hopefully there will be some more urgency now...

chriswarbo• 11 years ago

I think this serves as a good example of minimising one's attack surface.

The exploit is in the floppy disk controller, of a virtual machine, in an era when almost no physical machine includes a floppy disk drive, and those entering the field might never have seen a floppy disk other than the "File -> Save" icon; plus the exploit can be triggered even when the FDC is disabled.

Certainly a sobering thought for those using large, feature-filled applications 'just in case' some feature might be needed in the future.

TazeTSchnitzel3• 11 years ago

Yeah, it's bizarre how, in 2015, virtual machines often have floppy disk and CD-ROM drives and serial and parallel ports by default.

paulfurtado2• 11 years ago

To be fair, serial ports are actually really important and while we frequently don't have physical serial ports anymore, tons of devices still use serial emulation because it is such a simple technology to understand and the hard parts of the protocols are done in userland rather than drivers.

For managing virtual machines, it's more surprising that we give VMs VGA devices rather than just using serial: when using VGA emulation, you cannot trivially write code that reads text on the VM's screen, but if you configure the VM to use a serial console, you can trivially write a program which controls the VM. In a libvirt-managed qemu environment when the OS has its serial console enabled, you can run "virsh console MyVM" and instantly start executing commands and parsing their output. You can also have the OS write its log to serial so that if the OS crashes you can still read the full log. When all else fails, serial still works. Additionally, a virtual VGA device has an infinitely larger attack surface than a serial device.

When doing unattended windows installs, a lot of people use floppy drives to store the Autounattend.xml file. Floppy disk images are the most trivial and smallest images for automation tools to create. They're additionally useful for placing a linux bootloader on to boot a linux install CD with command line parameters.

Most people still use CD-ROM images to install operating systems, and it's basically required for windows. Virtual machine management software also tends to use the cd drive to install guest tools since it's the easiest way to let the guest see large files from outside the VM - nearly every OS can read CDs.

andrewchambers2• 11 years ago

If you have ever written VM software, the serial port is the first thing you implement in order to get some output from the kernel at boot.

locacorten• 11 years ago

There's no need for the floppy device code to be running in the VMM. Researchers have pointed this out for a long time:

Eurosys 2012: http://dl.acm.org/citation.cfm?id=2168851

commentnull• 11 years ago

Code reuse is great, unless it is Qemu?

wmf• 11 years ago

Or OpenSSL, or bash...

If there's a solution to this problem, I don't know what it is. Trying to replace an underfunded monoculture with severely underfunded diverse implementations may not even work and may actually reduce security.

sneak7• 11 years ago

Backronyms are lame, whether they are USA-PATRIOT or VENOM.

Why does it need to be an acronym? Just name it.

muraiki• 11 years ago

Can someone help me understand something? If a VM has no attached floppy drive, is it still vulnerable? The site says that disabling a virtual floppy drive is not enough, but if there's no floppy drive at all is that still a problem?

Edit: This comment seems to indicate that even lacking a virtual floppy drive, the floppy drive controller is still present and thus the system is vulnerable: https://news.ycombinator.com/item?id=9539191

Cacti• 11 years ago

This is up to the VM provider. I haven't seen a list yet except that this doesn't affect VirtualBox (if no floppy is mounted, the exploit is not possible).

One would expect though that there is no issue if a floppy drive is not attached, and hope that there is not a separate security hole to mount a floppy from sandboxed code (unlikely).

ponytech• 11 years ago

Is VirtualBox affected? It is not mentionned

jsabo2• 11 years ago

Other articles mention virtualbox is affected: http://www.zdnet.com/article/venom-security-flaw-millions-of...

Oracle, which develops VirtualBox, said in an emailed statement that the company was "aware" of the problem, and fixed the code, adding that it will release a maintenance update soon.

"We will release a VirtualBox 4.3 maintenance release very soon. Apart from this, only a limited amount of users should be affected as the floppy device emulation is disabled for most of the standard virtual machine configurations," said software lead Frank Mehnert.

fl0wenol• 11 years ago

The specific vulnerability and the fix:

https://github.com/qemu/qemu/commit/e907746266721f305d67bc07...

dogma11383• 11 years ago

Seriously every vulnerability will have it's own cool name and a website now? Even this? Not a single vendor has classified this as even critical. Yes like all security vulnerabilities it should be taken seriously, but when every clown out there goes all heart bleed on you for every security vulnerability they find because it's the smart marketing move today you stop taking them seriously which in the end is counter productive to this whole "raising awareness" BS they are trying to do....;

AgentME• 11 years ago

A VM escape vulnerability is pretty serious as vulnerabilities go!

dogma11383• 11 years ago

I don't disagree, however with no actual exploit (in the wild or POC according to RH), no confirmation of the ability to execute code on the actual host, so yes important but doesn't really justify the whole name and landing page ordeal.

Not because it's not important, but because it just desensitizes the whole impact of vulnerabilities the caliber of Heartbleed or Shellshock which did affect a large chunk of the servers and machines connected to the internet at the time.

Now they claim it's bigger than heartbleed, but with no exploit, and no clear statement on what actual in use implementations are affected, Amazon already have came out saying that VENOM has never affected their implementation of Xen, if Digital Ocean and Rackspace come out with the same statement it just makes this whole "bigger than HB stance" is silly.

And as far as the corporate/enterprise world goes, well VMware, CISCO, and MSFT hypervisors have a much bigger share out there and their hypervisors are not affected so again no much of a bite there.

DINKDINK• 11 years ago

Seriously every vulnerability will have it's own cool name and a website now?

is your argument that awareness of this issue would have been better if there wasn't a cool name and website?

dogma11383• 11 years ago

My argument is that raising awareness needs to be done in a tasteful manner, not spreading panic and using pop cloture references.

VIRTUALIZED ENVIRONMENT NEGLECTED OPERATIONS MANIPULATION VENOM seriously, kinda reminds me of:

Ward: Strategic Homeland Intervention, Enforcement and Logistics Division.

Hill: And what does that mean to you?

Ward: It means someone really wanted our initials to spell out "SHIELD."

At least heartbleed and shellshock were kinda properly named, this one is a hell of a stretch.

Inb4 people start registering silly domains that can be used to spell out vulnerabilities.

CITRUS: Channel Insecure Transport Releases User Sessions

TBONE: Transmission Buffer Overflow Network Exploitation

BUTTER: Buffer Underrun Transactional Execution Relay

Let the parking wars begin!

tomc1985• 11 years ago

Getting really tired of these slick vuln websites....

technicalfault• 11 years ago

I'm happy to report that we've completely patched our BigV cloud platform in four hours without needing customers to reboot http://forum.bytemark.co.uk/t/venom-new-vulnerability-affect...

jgome2• 11 years ago

How do I protect myself from the VENOM vulnerability?
If you administer a system running Xen, KVM, or the native QEMU client, review and apply the latest patches developed to address this vulnerability.
If you have a vendor service or device using one of the affected hypervisors, contact the vendor’s support team to see if their staff has applied the latest VENOM patches.

Or you could, you know, search for "qemu disable floppy" in google, read a bit and apply this flag to the VM:

qemu -global isa-fdc.driveA=

or -nodefaults to only enable the devices you want to enable...

https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg004...

hackcasual• 11 years ago

"And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers."

jgome2• 11 years ago

Yeah, sorry, I wrote whatever came to my mind before reading everything...

gtirloni• 11 years ago

Nowadays security research looks like a lot of extra work. Having to do the research and also think about a logo, website design, choice of colors, pretty diagrams, a cool name, social media interaction, market research to make sure all that isn't too similar to previous bugs. Eww!

eyeareque• 11 years ago

So much marketing. It's sort of hard to take these companies seriously.

Couldn't you just disable the floppy device in the vm?

TazeTSchnitzel3• 11 years ago

If you'd read the OP before commenting, you'd know the answer. (No.)

donjaxon• 11 years ago

VirtualBox is affected in a different/partial way. Summary: Patch to 4.3.28, released today.

The vulnerability is not mentioned explicitly in the change log. It only shows up as one of 32 bullet points "Floppy: several fixes". The actual changes are recorded only as "2015-05-08 12:58 Changeset in vbox [55753] by vboxsync: FDC: Fixed DRIVE SPECIFICATION command".

The fixed file from the QEMU project is:

http://git.qemu.org/?p=qemu.git;a=blob;f=hw/block/fdc.c;h=f7...

VirtualBox's equivalent file is:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devic...

There were some changes related to command buffers five days ago by Frank, but they only address FD_CMD_DRIVE_SPECIFICATION_COMMAND (in a slightly different way than QEMU's developers did it). The VirtualBox source code diffs are at:

https://www.virtualbox.org/changeset/55753/vbox

Compare to the QEMU diffs at:

http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721...

The vulnerability does not affect the current VirtualBox FD_CMD_READ_ID or the versions of the file going way. Maybe because it might have been forked as far back as 2003? Crowdstrike did point out that the vulnerability was present from 2004. But the vulnerability manifests in two bugs, one of which appears to affect VirtualBox and the other not.

andrewchambers2• 11 years ago

This is serious, but not that bad. First you need to actually get code running on the VM in the first place.

yaniksilver• 11 years ago

Cloudways provide three cloud infrastructure providers to host applications. We asked our point of contact with Amazon AWS, Google Compute Engine and DigitalOcean and here is what they respond.

DigitalOcean (DO): Being Patched. (The DO staff are busy in rolling out security updates. The patch will automatically be applied on DO servers inside Cloudways Platform.)

Amazon Web Service: Officially confirmed to be Safe.

Google Compute Engine: Officially confirmed to be Safe. (A Google representative informed Cloudways, “Google Cloud Platform was never vulnerable to this flaw. We do not use the vulnerable software.”)

http://www.cloudways.com/blog/venom-vulnerability/

Venom – A security vulnerability in virtual floppy drive code

Related Stories