Venom – A security vulnerability in virtual floppy drive code • Hacker News Board

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

#31

Post by justincormack » Wed, May 13, 2015, 1:45 PM UTC

duaneb wrote: post #21

mhayden wrote: post #13

Earlier quoted context omitted.

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

If I were amazon, I would have done an audit of the hyperv software and removed the floppy driver code entirely if unused for precisely this reason. This strikes me as a basic, "no-brainer" hardening step for my billion dollar(s) hosting business.

Their PV domains are not affected anyway. Quite possibly they are running qemu in stub domains for HVM as well, rather than on dom0, but you may well be right about the floppy code too.

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

#32

Post by lloeki » Wed, May 13, 2015, 1:55 PM UTC

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.

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

#33

Post by rolandr » Wed, May 13, 2015, 1:55 PM UTC

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.

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

#34

Post by drzaiusapelord » Wed, May 13, 2015, 1:56 PM UTC

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…

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

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

#35

Post by [deleted] » Wed, May 13, 2015, 1:56 PM UTC

[deleted]

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

#36

Post by drzaiusapelord » Wed, May 13, 2015, 1:58 PM UTC

cesarb wrote: post #25

brohee wrote: post #3

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

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

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.

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

#37

Post by tgeek » Wed, May 13, 2015, 1:59 PM UTC

cesarb wrote: post #25

brohee wrote: post #3

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

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

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

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

#38

Post by dsr_ » Wed, May 13, 2015, 2:01 PM UTC

drzaiusapelord wrote: post #34

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…

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

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.

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

#39

Post by rwmj » Wed, May 13, 2015, 2:02 PM UTC

drzaiusapelord wrote: post #34

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…

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

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.

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

#40

Post by chriswarbo » Wed, May 13, 2015, 2:06 PM UTC

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.