Backronyms are lame, whether they are USA-PATRIOT or VENOM.
Why does it need to be an acronym? Just name it.
Venom – A security vulnerability in virtual floppy drive code
61–70 of 124 posts
Re: Venom – A security vulnerability in virtual floppy drive code
#62Can someone help me understand something? If a VM has no attached floppy drive, is it still vulnerable? The site says that disabling a virtual floppy drive is not enough, but if there's no floppy drive at all is that still a problem?
"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."
Edit: This comment seems to indicate that even lacking a virtual floppy drive, the floppy drive controller is still present and thus the system is vulnerable: https://news.ycombinator.com/item?id=9539191
Re: Venom – A security vulnerability in virtual floppy drive code
#63A 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 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.
Re: Venom – A security vulnerability in virtual floppy drive code
#64Amazon 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.
You do not have to be a large company to get on the Xen pre-disclosure list.
http://www.xenproject.org/security-policy.html
----------
Public hosting providers;
Large-scale organisational users of Xen;
Vendors of Xen-based systems;
Distributors of operating systems with Xen support.
Here "provider", "vendor", and "distributor" is meant to include anyone who is making a genuine service, available to the public, whether for a fee or gratis. For projects providing a service for a fee, the rule of thumb of "genuine" is that you are offering services which people are purchasing. For gratis projects, the rule of thumb for "genuine" is measured in terms of the amount of time committed to providing the service. For instance, a software project which has 2-3 active developers, each of whom spend 3-4 hours per week doing development, is very likely to be accepted; whereas a project with a single developer who spends a few hours a month will most likey be rejected.
----------
Basically, if you provide a service to the public which uses Xen (Not restricted on size), or use Xen at large scale internally, you can get on the list. There are several small hosting providers that utilize Xen on that list.
Presumably if you use Xen at small scale internally you're less worried about security vulnerabilities as it is only your employees with root access to the machines - if external users have root access, you probably fall under one of the other definitions.
Re: Venom – A security vulnerability in virtual floppy drive code
#65A 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.)
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:
https://fedoraproject.org/wiki/Features/SVirt_Mandatory_Acce...
Re: Venom – A security vulnerability in virtual floppy drive code
#66Is VirtualBox affected? It is not mentionned
Re: Venom – A security vulnerability in virtual floppy drive code
#67Earlier quoted context omitted.
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 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.
Re: Venom – A security vulnerability in virtual floppy drive code
#68Amazon 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.
Or, AWS takes steps to mitigate their exposure, regardless of whether or not they receive embargoed disclosures.
On the Rackspace public cloud I've been through three full-fleet reboot cycles so far. Only one of those affected AWS customers, and AWS handled it in such a way that only a portion of their fleet was affected.
How could AWS do this when Rackspace and others couldn't?
For one, they could stratify guest placement based on instance type and guest OS. (Which I hear they do.) Most recent XSAs have only affected PV or HVM guests, not both. If you keep PV and HVM guests separate ...
AWS seems to be an example of good engineering, not an example of the perils of capitalism.
Re: Venom – A security vulnerability in virtual floppy drive code
#69Is VirtualBox affected? It is not mentionned
Other articles mention virtualbox is affected:
http://www.zdnet.com/article/venom-security-flaw-millions-of...
Oracle, which develops VirtualBox, said in an emailed statement that the company was "aware" of the problem, and fixed the code, adding that it will release a maintenance update soon.
"We will release a VirtualBox 4.3 maintenance release very soon. Apart from this, only a limited amount of users should be affected as the floppy device emulation is disabled for most of the standard virtual machine configurations," said software lead Frank Mehnert.
Re: Venom – A security vulnerability in virtual floppy drive code
#70The specific vulnerability and the fix:
https://github.com/qemu/qemu/commit/e907746266721f305d67bc07...