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?
Venom – A security vulnerability in virtual floppy drive code
11–20 of 124 posts
Re: Venom – A security vulnerability in virtual floppy drive code
#12Since 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?
"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."
Re: Venom – A security vulnerability in virtual floppy drive code
#13Amazon 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...
The vulnerability is in floppy drive emulator code. It isn't clear to me whether all users are vulnerable or only hosts that have floppy drive devices defined [in their guests] are vulnerable. If the latter, perhaps Amazon was never vulnerable anyway?
The exploit affects VM's whether or not they have a floppy controller or disk attached.
Re: Venom – A security vulnerability in virtual floppy drive code
#14Amazon 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...
The vulnerability is in floppy drive emulator code. It isn't clear to me whether all users are vulnerable or only hosts that have floppy drive devices defined [in their guests] are vulnerable. If the latter, perhaps Amazon was never vulnerable anyway?
The disclosure states that due to another bug, even floppy less hosts were vulnerable...
Re: Venom – A security vulnerability in virtual floppy drive code
#15A 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.
Re: Venom – A security vulnerability in virtual floppy drive code
#16Amazon 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...
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.
It is a necessary evil, no need for the rhetoric.
Profit and PR are hardly the goal here -- community awareness and public safety are paramount. Vulnerabilities need to be obviated to the general populace at large.
Re: Venom – A security vulnerability in virtual floppy drive code
#17Since 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?
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.
Re: Venom – A security vulnerability in virtual floppy drive code
#18[...] 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.
Re: Venom – A security vulnerability in virtual floppy drive code
#19"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…
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.
Re: Venom – A security vulnerability in virtual floppy drive code
#20I 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.