Code reuse is great, unless it is Qemu?
Venom – A security vulnerability in virtual floppy drive code
51–60 of 124 posts
Re: Venom – A security vulnerability in virtual floppy drive code
#52Earlier quoted context omitted.
>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.
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 in…
If that's disabling the floppy as a boot drive, we do that in KVM by default. :) But the device is still there, even if you disable booting it from there.
Re: Venom – A security vulnerability in virtual floppy drive code
#53I 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.
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.
Re: Venom – A security vulnerability in virtual floppy drive code
#54Earlier quoted context omitted.
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 in…
If that's disabling the floppy as a boot drive, we do that in KVM by default. :) But the device is still there, even if you disable booting it from there.
Yeah, I mean going into the BIOS setting for Floppy Drive and hitting + until it rotates around various disk dimensions, and finally says [Disabled]. :)
That's the only way I've found to remove it from the list of drives that WMI's win32_physicaldisk class presents.
Re: Venom – A security vulnerability in virtual floppy drive code
#55Earlier quoted context omitted.
>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.
The administrator can decide to leave the bay empty, but the drive and controller simply cannot be disabled. That's not a bug, simply there's no code and no option at all to do it.
Re: Venom – A security vulnerability in virtual floppy drive code
#56The 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.
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.
Re: Venom – A security vulnerability in virtual floppy drive code
#57[...] 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…
They don't have a virtual floppy drive, but they do have a virtual floppy drive _controller_.
Re: Venom – A security vulnerability in virtual floppy drive code
#58A 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…
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.)
Re: Venom – A security vulnerability in virtual floppy drive code
#59A 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.
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.
Re: Venom – A security vulnerability in virtual floppy drive code
#60"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…
Isn't that the appeal of KVM, though? It's just the Linux kernel, instead of a new thing like Xen?