[deleted]
Venom – A security vulnerability in virtual floppy drive code
81–90 of 124 posts
Re: Venom – A security vulnerability in virtual floppy drive code
#82Venom... really... ugh
Where's G.I. Joe when we need him?
Re: Venom – A security vulnerability in virtual floppy drive code
#83Can 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…
This is up to the VM provider. I haven't seen a list yet except that this doesn't affect VirtualBox (if no floppy is mounted, the exploit is not possible).
One would expect though that there is no issue if a floppy drive is not attached, and hope that there is not a separate security hole to mount a floppy from sandboxed code (unlikely).
Re: Venom – A security vulnerability in virtual floppy drive code
#84> How do I protect myself from the VENOM vulnerability?
> If you administer a system running Xen, KVM, or the native QEMU client, review and apply the latest patches developed to address this vulnerability.
> If you have a vendor service or device using one of the affected hypervisors, contact the vendor’s support team to see if their staff has applied the latest VENOM patches.
Or you could, you know, search for "qemu disable floppy" in google, read a bit and apply this flag to the VM:
qemu -global isa-fdc.driveA=
or -nodefaults to only enable the devices you want to enable...
https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg004...
Re: Venom – A security vulnerability in virtual floppy drive code
#85> How do I protect myself from the VENOM vulnerability? > If you administer a system running Xen, KVM, or the native QEMU client, review and apply the latest patches developed to address this vulnerability. > If you have a vendor service or device using one of the affected hypervisors, contact the vendor’s support team to see if their staff has applied the latest VENOM patches. Or you could, you know, search for "qem…
"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
#86A 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.
> How many people need a floppy disk controller?
Raises hand
Re: Venom – A security vulnerability in virtual floppy drive code
#87> How do I protect myself from the VENOM vulnerability? > If you administer a system running Xen, KVM, or the native QEMU client, review and apply the latest patches developed to address this vulnerability. > If you have a vendor service or device using one of the affected hypervisors, contact the vendor’s support team to see if their staff has applied the latest VENOM patches. Or you could, you know, search for "qem…
"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."
Yeah, sorry, I wrote whatever came to my mind before reading everything...
Re: Venom – A security vulnerability in virtual floppy drive code
#88I 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.
Why don't you like this trend? I don't see the harm. Also, the FAQ explains a lot; including the details of how the vulnerability works.
It means that folks with little to no technical experience (read: authors of WiReD articles) will latch onto the new buzzword and start regurgitating it left and right, eventually tricking other technologically-illiterate people to latch onto it and start pelting me with questions like "OMG DID YOU HEAR ABOUT VENOM???!!!" and "OMG U BUTTR PASH UR SURVURZ OMGOMGLOL!!!!111one" instead of letting me do my job. All because the publishers want to satisfy their attention-seeking desires ("LOOK AT ME I FOUND A SECURITY BUG AND GAVE IT A HIP COOL BUZZWORD I'M SO SPECIAL!!!!").
I personally don't like the trend for the same reason why I dislike terminology like "ninja" or "rockstar" or "badass" or "devops". It cheapens computer science/engineering into resembling something a bunch of hip middle schoolers yammer on about alongside their video games and their skateboards instead of the multi-billion-dollar professional field it actually is.
Re: Venom – A security vulnerability in virtual floppy drive code
#89Nowadays security research looks like a lot of extra work. Having to do the research and also think about a logo, website design, choice of colors, pretty diagrams, a cool name, social media interaction, market research to make sure all that isn't too similar to previous bugs. Eww!
Re: Venom – A security vulnerability in virtual floppy drive code
#90I 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 makes sense for the ones that require mass mobilization and mass education to fix. This vulnerability isn't quite that... there are relatively fewer people managing VM infrastructure, and this only affects certain types of VMs. That said, it's really hard to market security companies in ways that represent the hard work that they do, in ways that are not all snake oil and spin. So it's hard to blame folks for tryi…
> require mass mobilization and mass education to fix
Except that Crowdstrike is heavily involved in 'threat intelligence' so this isn't really about patching vulnerabilities at the technical level but educating non-technical executives on threats and 'threat actors'. So corporate execs can be handed a dossier of recent events, like they were the US President evaluating their national security policy.
The only problem is that threat intelligence has marginal value, as infosec changes so rapidly and is so diverse, so at the end of the day it is very much simply emotional gratification - that Crowdstrike delivers at a very high price.
In terms of resource utilization, it doesn't seem like a good use of time/money to obsess over each bug as if it were an atypical event in a slow moving enviornment. But hey if it gets a few people at the top to start caring about security, maybe there is some value... I just hope it doesn't result in execs nagging the infosec team for updates on 'venom' and disrupting their work on real security measures for the company by focusing on the latest hot topic.