
Venom – A security vulnerability in virtual floppy drive code - fulafel
http://venom.crowdstrike.com/
======
rwmj
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](https://bugzilla.redhat.com/show_bug.cgi?id=1218611)

~~~
drzaiusapelord
>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_
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.

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

Incompetence on top of incompetence doesn't invalidate my argument. Minimizing
your attack surface should be the norm, unfortunately here on HN it just leads
to downvotes.

~~~
rwmj
RHEL cuts tons of devices compared to upstream qemu. Go and grab the source
RPM and see the number of '\--disable-XXX' options and the additional patches
we add to remove devices. We publish a whitelist of devices we allow [which
unfortunately I cannot find now, but it's in the RHEL docs online], and
anything else is cut.

------
orf
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.

~~~
butwhy
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.

~~~
yellowapple
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.

------
mariusz79
"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...](http://www.electricmonk.nl/log/2007/10/25/virtualization-security/)

~~~
agentultra
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
> 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.

~~~
cthalupa
>timers through the direct Xen shared_info page

HVM has support PV timers (and interrupt controllers, and spinlocks) for quite
some time now

>generally as "native" to x86 as Xen permits.

I really don't know if I agree with this. With hardware extensions basic CPU
performance is going to be significantly better on HVM instances (No longer
having to bounce to the hypervisor every time you make a system call since you
once again have three CPU protection rings with ring -1), and that's before
getting into SR-IOV, etc.

Unikernels are sweet and all, but without PVH, PV will outperform modern
"PVHVM" implementations, and with PVH you're still running in a partial HVM
shell.

~~~
cthalupa
Can't edit this anymore apparently, but correction: PV will _not_ outperform
modern "PVHVM"

------
alricb
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...](http://git.qemu.org/?p=qemu.git;a=blob;f=hw/block/fdc.c;hb=24a5c62cfe3cbe3fb4722f79661b9900a2579316#l1918)

fdctrl_stop_transfer() might be one of the incriminated functions.

~~~
thrownaway2424
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.

~~~
breakingcups
The diff is literaly linked in the article.

~~~
thrownaway2424
The original site, and my comment, are from 9 days ago. The linked diff is
from 7 days ago.

------
fulafel
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](http://xenbits.xen.org/xsa/advisory-133.html)

------
fl0wenol
The specific vulnerability and the fix:

[https://github.com/qemu/qemu/commit/e907746266721f305d67bc07...](https://github.com/qemu/qemu/commit/e907746266721f305d67bc0718795fedee2e824c)

------
dogma1138
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
A VM escape vulnerability is pretty serious as vulnerabilities go!

~~~
dogma1138
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.

------
donjaxon
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...](http://git.qemu.org/?p=qemu.git;a=blob;f=hw/block/fdc.c;h=f72a39216347e722496797555db9f208b0c5b4b2)

VirtualBox's equivalent file is:

[https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devic...](https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Storage/DevFdc.cpp)

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](https://www.virtualbox.org/changeset/55753/vbox)

Compare to the QEMU diffs at:

[http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721...](http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721f305d67bc0718795fedee2e824c)

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.

------
chriswarbo
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.

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

~~~
paulfurtado
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.

~~~
TazeTSchnitzel
> 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.

To be sure! But it's not always necessary.

> When doing unattended windows installs, a lot of people use floppy drives to
> store the Autounattend.xml file.

> Most people still use CD-ROM images to install operating systems,

Also both true, but they shouldn't be available unless you need them.

~~~
paulfurtado
Not always necessary, but I think it's useful, if not important, to have by
default in any infrastructure which uses long-term VMs and doesn't just
replace "immutable" VMs every time a setting is changed. You always want some
path to get data into the VM without networking or VGA, otherwise you have a
big problem when something goes wrong with the network and you need to fix
things in VMs which you don't want to reboot. This is a corner I'm sure enough
sysadmins have found themselves in.

For extra-security-conscious deployments, most hypervisors let you remove most
hardware, and qemu gives you enough flexibility to define nearly every device
on the VM's motherboard at the command line rather than taking a pre-
configured motherboard setup. The default settings in most hypervisors give
you lots of unneeded hardware, but this hardware is really convenient for any
user who is just trying to get a VM up.

I realize that, from a "secure defaults" perspective, the CD-rom and unused
serial port increase your attack surface, but I also think this trade is worth
it in most scenarios, but it's a tough line to draw.

------
gtirloni
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!

------
brohee
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...](https://aws.amazon.com/security/security-
bulletins/XSA_Security_Advisory_CVE_2015_3456/)

~~~
sneak
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.

~~~
Anderkent
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?

~~~
sneak
I'm not insisting anything. I'm just saying that lack of immediate and full
disclosure is essentially crony capitalism where there are the Big Important
Companies That Must Be Protected and then there is everybody else, including
small startups and private individuals.

It is fundamentally unfair, and sets up a non-level playing field.

(inb4 "critical infrastructure")

~~~
res0nat0r
I think it is even simpler than that: The big companies that have thousands of
customers doing millions of dollars of business on hundreds of thousands of
machines need more time to patch because their is much more money / business
to be lost. Not giving large companies time to patch would do more harm than
good in the end.

It is fundamentally unfair, and is perfectly reasonable.

------
rolandr
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.

~~~
justincormack
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...

------
locacorten
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](http://dl.acm.org/citation.cfm?id=2168851)

------
muraiki
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?

"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."

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](https://news.ycombinator.com/item?id=9539191)

~~~
Cacti
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).

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

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

------
technicalfault
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...](http://forum.bytemark.co.uk/t/venom-new-vulnerability-affecting-
bigv-and-legacy-vms-cve-2015-3456/2255/6?u=joshr)

------
yaniksilver
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/﻿](http://www.cloudways.com/blog/venom-vulnerability/﻿)

------
ponytech
Is VirtualBox affected? It is not mentionned

~~~
jsabo
Other articles mention virtualbox is affected:
[http://www.zdnet.com/article/venom-security-flaw-millions-
of...](http://www.zdnet.com/article/venom-security-flaw-millions-of-virtual-
machines-datacenters/)

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.

------
specto
Venom... really... ugh

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

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

------
rlpb
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?

~~~
mcintyre1994
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.

------
commentnull
Code reuse is great, unless it is Qemu?

~~~
wmf
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.

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

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

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

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

------
gvb
[...] _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
You didn't read much of the page :)

To quote:

"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."

------
jgome
> 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...](https://lists.gnu.org/archive/html/qemu-
devel/2013-02/msg00434.html)

~~~
hackcasual
"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."

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

