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

91–100 of 124 posts

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

#91

Post by rmetzler »

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.

I like to have a name to refer to, instead of "you know this vulnerability CVE-2015-xxxx affecting this software we use on some machines in some of our data centers".

I find it much easier to talk about heartbleed or shellshock (which is like ~7 different bugs). But googling for bugs and to find out which versions/patches fix this bug, I'll still need the CVE number.

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

#92

Post by AgentME »

dogma1138 wrote: post #73

Seriously every vulnerability will have it's own cool name and a website now? Even this? Not a single vendor has classified this as even critical. Yes like all security vulnerabilities it should be taken seriously, but when every clown out there goes all heart bleed on you for every security vulnerability they find because it's the smart marketing move today you stop taking them seriously which in the end is counter…

A VM escape vulnerability is pretty serious as vulnerabilities go!

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

#95

Post by TazeTSchnitzel »

chriswarbo wrote: post #40

I think this serves as a good example of minimising one's attack surface. The exploit is in the floppy disk controller, of a virtual machine, in an era when almost no physical machine includes a floppy disk drive, and those entering the field might never have seen a floppy disk other than the "File -> Save" icon; plus the exploit can be triggered even when the FDC is disabled. Certainly a sobering thought for those u…

Yeah, it's bizarre how, in 2015, virtual machines often have floppy disk and CD-ROM drives and serial and parallel ports by default.

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

#96

Post by LnxPrgr3 »

thrownaway2424 wrote: post #56
alricb wrote: post #26

The missing reset of the fifo is in one of the handlers defined at http://git.qemu.org/?p=qemu.git;a=blob;f=hw/block/fdc.c;hb=2... fdctrl_stop_transfer() might be one of the incriminated functions.

I like how I had to read 100 comments on Hacker News to learn this information. Vulnerability disclosure just isn't what it used to be.

A shame, too, because there's a (small, admittedly) lesson buried in the fix--one that can be applied even in low-level languages.

If you have a buffer with odd semantics (such as wrapping out-of-bounds addresses back into bounds), it should probably be wrapped in something that enforces that. In C++, it could be made to look like a normal buffer, except that operator[] is overloaded to wrap for you, and you can make the compiler scream at you if you try to escape that safety net--for an inline class, very likely without any performance cost over adding the wrapping computation to each access by hand.

In C, your options are more limited. The safest is an opaque handle that has to be passed to an accessor function. You're more likely to take a performance hit (unless LTO fixes it for you), but in a floppy drive emulator, I doubt it matters.

If the overhead does matter, a macro or static inline function still makes the access convention easier to memorize, which should make it less likely for someone to forget, and should make code that does forget more suspicious on code review.

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

#98

Post by dogma1138 »

AgentME wrote: post #92
dogma1138 wrote: post #73

Seriously every vulnerability will have it's own cool name and a website now? Even this? Not a single vendor has classified this as even critical. Yes like all security vulnerabilities it should be taken seriously, but when every clown out there goes all heart bleed on you for every security vulnerability they find because it's the smart marketing move today you stop taking them seriously which in the end is counter…

A VM escape vulnerability is pretty serious as vulnerabilities go!

I don't disagree, however with no actual exploit (in the wild or POC according to RH), no confirmation of the ability to execute code on the actual host, so yes important but doesn't really justify the whole name and landing page ordeal.

Not because it's not important, but because it just desensitizes the whole impact of vulnerabilities the caliber of Heartbleed or Shellshock which did affect a large chunk of the servers and machines connected to the internet at the time.

Now they claim it's bigger than heartbleed, but with no exploit, and no clear statement on what actual in use implementations are affected, Amazon already have came out saying that VENOM has never affected their implementation of Xen, if Digital Ocean and Rackspace come out with the same statement it just makes this whole "bigger than HB stance" is silly.

And as far as the corporate/enterprise world goes, well VMware, CISCO, and MSFT hypervisors have a much bigger share out there and their hypervisors are not affected so again no much of a bite there.

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

#99

Post by DINKDINK »

dogma1138 wrote: post #73

Seriously every vulnerability will have it's own cool name and a website now? Even this? Not a single vendor has classified this as even critical. Yes like all security vulnerabilities it should be taken seriously, but when every clown out there goes all heart bleed on you for every security vulnerability they find because it's the smart marketing move today you stop taking them seriously which in the end is counter…

>Seriously every vulnerability will have it's own cool name and a website now?

is your argument that awareness of this issue would have been better if there wasn't a cool name and website?

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

#100

Post by cthalupa »

avsm wrote: post #30
agentultra wrote: post #19

Earlier quoted context omitted.

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.

>timers through the direct Xen shared_info page

HVM has support PV timers (and interrupt controllers, and spinlocks) for quite some time now

>generally as "native" to x86 as Xen permits.

I really don't know if I agree with this. With hardware extensions basic CPU performance is going to be significantly better on HVM instances (No longer having to bounce to the hypervisor every time you make a system call since you once again have three CPU protection rings with ring -1), and that's before getting into SR-IOV, etc.

Unikernels are sweet and all, but without PVH, PV will outperform modern "PVHVM" implementations, and with PVH you're still running in a partial HVM shell.

Post reply on HN