Live data from Hacker News

Venom – A security vulnerability in virtual floppy drive code

venom.crowdstrike.com

111–120 of 124 posts

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

#112

Earlier quoted context omitted.

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

My argument is that raising awareness needs to be done in a tasteful manner, not spreading panic and using pop cloture references. VIRTUALIZED ENVIRONMENT NEGLECTED OPERATIONS MANIPULATION VENOM seriously, kinda reminds me of: Ward: Strategic Homeland Intervention, Enforcement and Logistics Division. Hill: And what does that mean to you? Ward: It means someone really wanted our initials to spell out "SHIELD." At leas…

They need to sound way scarier than that, though.

BONECRUSH: Buffer Overrun Neatly Exceeds Current Reusable User Storage Hindrances

FACENEEDLE: Foreign Actors Can Execute Nefarious Executables, Even During Lockdown... Exploit

HELLSCREAM: Hack Exploiting Lazy Loading Standard Core Runtime Executables And Modules

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

#113
post #41

Earlier quoted context omitted.

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")

Why, might I ask, is fairness required? I'll stipulate that you're correct about said fairness although I could dispute that pretty easily

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

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

I think my new hobby is to go around vulnerability threads and ask whether they'd be possible if the thing was written in Rust, and tally the results.

I haven't even especially tried Rust, but I think it's time for a safer language/compiler.

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

#115
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…

It's why I try to deploy xen dom0s without any QEMU installed at all; reading through past xen CVEs was enough to convince me that HVM guests seem more exposed.. If anybody knows a writeup on what you might lose in terms of isolation and protection from guest escapes by sticking to PV, please do share

Paravirtualization loses instructions which are useful for high performance computing. That's not relevant to isolation/protection... but it is worth mentioning.

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

#116
post #30

Earlier quoted context omitted.

> 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 o…

Can't edit this anymore apparently, but correction: PV will not outperform modern "PVHVM"

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

#117

Earlier quoted context omitted.

It's why I try to deploy xen dom0s without any QEMU installed at all; reading through past xen CVEs was enough to convince me that HVM guests seem more exposed.. If anybody knows a writeup on what you might lose in terms of isolation and protection from guest escapes by sticking to PV, please do share

Paravirtualization loses instructions which are useful for high performance computing. That's not relevant to isolation/protection... but it is worth mentioning.

Like what? And is that an intrinsic loss, or is it a limitation of existing software, or is it a limitation of existing hardware?

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

#118

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.

> How many people need a floppy disk controller? Raises hand

What for, may I ask?

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

#119
Cloudways provide three cloud infrastructure providers to host applications. We asked our point of contact with Amazon AWS, Google Compute Engine and DigitalOcean and here is what they respond.

DigitalOcean (DO): Being Patched. (The DO staff are busy in rolling out security updates. The patch will automatically be applied on DO servers inside Cloudways Platform.)

Amazon Web Service: Officially confirmed to be Safe.

Google Compute Engine: Officially confirmed to be Safe. (A Google representative informed Cloudways, “Google Cloud Platform was never vulnerable to this flaw. We do not use the vulnerable software.”)

http://www.cloudways.com/blog/venom-vulnerability/

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

#120

Earlier quoted context omitted.

> How many people need a floppy disk controller? Raises hand

What for, may I ask?

My main use of QEMU is to run (in isolation, preferably) old software, whether it's some ancient game or some ancient accounting software or what have you. Said software is usually distributed as floppies (or, nowadays in a world where virtualization is hot shit) floppy images. Thus, even in virtualized environments, there's still a use case, for me at least. I can use DOSBox for a lot of this, I'm sure, but not all the things I run on QEMU run on DOS (and some of the things which do run on DOS don't run on MS-DOS or FreeDOS).

In the physical world, I still maintain quite a few old computers (and I mean really old) that do things around the house or someone else's house. Many of these lack working CD-ROM drives and USB ports (let alone bootable USB ports), so the most surefire means to transfer data to/from them are either over a network (which depends on them having a NIC; this isn't always the case) or via floppies (which pretty much all of them have); floppy drives are also almost universally needed on these machines in order to boot OS installers (and, in some cases, even boot the main OS itself; I have at least one machine that boots off a floppy with GRUB in order to load an OS of choice off a USB thumbstick - one of the lucky few I have that has USB ports without supporting USB boot). Here, Linux having a floppy controller is incredibly useful (whether in virtualized or physical environments), since it makes it easier to create boot floppies and the like with `dd`.

Post reply on HN