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

41–50 of 124 posts

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

#41

Post by sneak »

Anderkent wrote: post #22
sneak wrote: post #8

Earlier quoted context omitted.

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?

I'm not insisting anything. I'm just saying that lack of immediate and full disclosure is essentially crony capitalism where there are the Big Important Companies That Must Be Protected and then there is everybody else, including small startups and private individuals.

It is fundamentally unfair, and sets up a non-level playing field.

(inb4 "critical infrastructure")

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

#42

Post by sneak »

duaneb wrote: post #23
sneak wrote: post #8

Earlier quoted context omitted.

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?

Tell the entire market the information you have and let them do with it as they will, versus telling your friends first and letting everyone else go to hell.

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

#43

Post by stephengillie »

drzaiusapelord wrote: post #34
rwmj wrote: post #15

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…

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

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

#44

Post by userbinator »

drzaiusapelord wrote: post #34
rwmj wrote: post #15

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…

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

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.

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

#45

Post by sneak »

Anderkent wrote: post #22
sneak wrote: post #8

Earlier quoted context omitted.

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?

You seem to have twisted my "tell everyone and let the fittest survive and thrive" into some weird Harrison Bergeron thing which is the exact opposite of my point.

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

#46

Post by sneak »

Anderkent wrote: post #22
sneak wrote: post #8

Earlier quoted context omitted.

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?

To answer your question directly, it is bad because it gives them a massive unfair advantage over their smaller competitors. It favors incumbents versus favoring efficiency.

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

#47

Post by drzaiusapelord »

dsr_ wrote: post #38
drzaiusapelord wrote: post #34

Earlier quoted context omitted.

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

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.

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

#48

Post by userbinator »

rwmj wrote: post #15

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…

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.

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

#49

Post by sneak »

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.

Nobody does, really, but it turns out that we are all playing a marketing game every second of our lives. Some of us just don't realize it.

You can play, or you can abstain, but you can't abstain from the effects of abstaining (to paraphrase Rand).

Post reply on HN