Venom – A security vulnerability in virtual floppy drive code
111–120 of 124 posts
Re: Venom – A security vulnerability in virtual floppy drive code
#112Earlier 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…
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
#113Earlier 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")
Re: Venom – A security vulnerability in virtual floppy drive code
#114A 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 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
#115A 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
Re: Venom – A security vulnerability in virtual floppy drive code
#116Earlier 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…
Re: Venom – A security vulnerability in virtual floppy drive code
#117Earlier 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.
Re: Venom – A security vulnerability in virtual floppy drive code
#118Earlier 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
Re: Venom – A security vulnerability in virtual floppy drive code
#119DigitalOcean (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.”)
Re: Venom – A security vulnerability in virtual floppy drive code
#120Earlier quoted context omitted.
> How many people need a floppy disk controller? Raises hand
What for, may I ask?
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`.