Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Venom – A security vulnerability in virtual floppy drive code

venom.crowdstrike.com

Post reply on HN
Print view View original

101–110 of 124 posts

Re: Venom – A security vulnerability in virtual floppy drive code

#101

Post by 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...

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.

Re: Venom – A security vulnerability in virtual floppy drive code

#102

Post by dogma1138 »

DINKDINK wrote: post #99
dogma1138 wrote: post #73

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…

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

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!

Re: Venom – A security vulnerability in virtual floppy drive code

#103

Post by paulfurtado »

TazeTSchnitzel wrote: post #95
chriswarbo wrote: post #40

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 u…

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

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.

Re: Venom – A security vulnerability in virtual floppy drive code

#104

Post by TazeTSchnitzel »

paulfurtado wrote: post #103
TazeTSchnitzel wrote: post #95

Earlier quoted context omitted.

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

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 VG…

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

Re: Venom – A security vulnerability in virtual floppy drive code

#105

Post by csirac2 »

mariusz79 wrote: post #5

"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/virtual…

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

Re: Venom – A security vulnerability in virtual floppy drive code

#106

Post by csirac2 »

rwmj wrote: post #15

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…

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

Re: Venom – A security vulnerability in virtual floppy drive code

#107

Post by reinhardt »

dogma1138 wrote: post #102
DINKDINK wrote: post #99

Earlier quoted context omitted.

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

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 leas…

Quick, someone propose a .vln or .vuln gTLD!

Re: Venom – A security vulnerability in virtual floppy drive code

#108

Post by mattkrea »

lloeki wrote: post #32
orf wrote: post #20

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.

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.

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.

Re: Venom – A security vulnerability in virtual floppy drive code

#109

Post by paulfurtado »

TazeTSchnitzel wrote: post #104
paulfurtado wrote: post #103

Earlier quoted context omitted.

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 VG…

> 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 s…

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.

Re: Venom – A security vulnerability in virtual floppy drive code

#110

Post by andrewchambers »

TazeTSchnitzel wrote: post #95
chriswarbo wrote: post #40

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 u…

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

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.
Post reply on HN