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.
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.
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.)
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:
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.
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.
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.
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.
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.
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.
>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.
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.
My main use of QEMU is to run (in isolation, preferably) old software, whether it's some ancient game or some ancient accounting software or what have you. Said software is usually distributed as floppies (or, nowadays in a world where virtualization is hot shit) floppy images. Thus, even in virtualized environments, there's still a use case, for me at least. I can use DOSBox for a lot of this, I'm sure, but not all the things I run on QEMU run on DOS (and some of the things which do run on DOS don't run on MS-DOS or FreeDOS).
In the physical world, I still maintain quite a few old computers (and I mean really old) that do things around the house or someone else's house. Many of these lack working CD-ROM drives and USB ports (let alone bootable USB ports), so the most surefire means to transfer data to/from them are either over a network (which depends on them having a NIC; this isn't always the case) or via floppies (which pretty much all of them have); floppy drives are also almost universally needed on these machines in order to boot OS installers (and, in some cases, even boot the main OS itself; I have at least one machine that boots off a floppy with GRUB in order to load an OS of choice off a USB thumbstick - one of the lucky few I have that has USB ports without supporting USB boot). Here, Linux having a floppy controller is incredibly useful (whether in virtualized or physical environments), since it makes it easier to create boot floppies and the like with `dd`.
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
Paravirtualization loses instructions which are useful for high performance computing. That's not relevant to isolation/protection... but it is worth mentioning.
> 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?
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