Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Venom – A security vulnerability in virtual floppy drive code

venom.crowdstrike.com

Post reply on HN
Print view View original

21–30 of 124 posts

Re: Venom – A security vulnerability in virtual floppy drive code

#21

Post by duaneb »

mhayden wrote: post #13
rlpb wrote: post #10

Earlier quoted context omitted.

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.

If I were amazon, I would have done an audit of the hyperv software and removed the floppy driver code entirely if unused for precisely this reason. This strikes me as a basic, "no-brainer" hardening step for my billion dollar(s) hosting business.

Re: Venom – A security vulnerability in virtual floppy drive code

#22

Post by Anderkent »

sneak wrote: post #8
brohee wrote: post #3

Amazon 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.

How is it bad that large providers have an opportunity to patch before the vulnerability is released to the wild?

Maybe next you'll insist that everyone's prevented from patching for a week after disclosure so that smaller companies that don't have the resources to react immediately are not unfairly left behind?

Re: Venom – A security vulnerability in virtual floppy drive code

#23

Post by duaneb »

sneak wrote: post #8
brohee wrote: post #3

Amazon 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.

And the alternative?

Re: Venom – A security vulnerability in virtual floppy drive code

#24

Post by muppetman »

gvb wrote: post #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…

You didn't read much of the page :)

To quote:

"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

#25

Post by cesarb »

brohee wrote: post #3

Amazon 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...

Or perhaps they're using a custom-compiled Xen without the vulnerable floppy disk emulation.

Re: Venom – A security vulnerability in virtual floppy drive code

#27

Post by dantillberg »

orf wrote: post #20

I 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 trying to turn excellent security investigative work into self-promotional opportunities.

(Edits: clarity and trying not to sound judgmental of the parent comment)

Re: Venom – A security vulnerability in virtual floppy drive code

#28

Post by jpgvm »

duaneb wrote: post #21
mhayden wrote: post #13

Earlier quoted context omitted.

The exploit affects VM's whether or not they have a floppy controller or disk attached.

If I were amazon, I would have done an audit of the hyperv software and removed the floppy driver code entirely if unused for precisely this reason. This strikes me as a basic, "no-brainer" hardening step for my billion dollar(s) hosting business.

They use Xen, not Hyper-V and yes they already remove/replace large portions of Xen.

Re: Venom – A security vulnerability in virtual floppy drive code

#29

Post by butwhy »

orf wrote: post #20

I 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.

Re: Venom – A security vulnerability in virtual floppy drive code

#30

Post by avsm »

agentultra wrote: post #19
mariusz79 wrote: post #5

"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 isolat…

> I'm most interested in seeing how jitsu and unikernels can turn the tables

The useful aspect about the MirageOS unikernels is that they use the pure Xen PV interface, which has almost no dependency on qemu. No floppy or block/net emulation, timers through the direct Xen shared_info page, and generally as "native" to x86 as Xen permits.

Post reply on HN