Venom – A security vulnerability in virtual floppy drive code

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

That is the purpose of the cXXX,cYYY part of the label as seen in the example here:

https://fedoraproject.org/wiki/Features/SVirt_Mandatory_Acce...

Anyhow, security bugs happen (in all sorts of devices, old and new), and the important thing is that we fix them quickly and that SELinux mitigates the immediate effects.

Unfortunately I'm always working with established systems, so I can't push this feedback during the sales process.

Arguing about defaults requires a step back to policy level, which is something for which many projects have trouble finding time and attention.

Raises hand

Except that Crowdstrike is heavily involved in 'threat intelligence' so this isn't really about patching vulnerabilities at the technical level but educating non-technical executives on threats and 'threat actors'. So corporate execs can be handed a dossier of recent events, like they were the US President evaluating their national security policy.

The only problem is that threat intelligence has marginal value, as infosec changes so rapidly and is so diverse, so at the end of the day it is very much simply emotional gratification - that Crowdstrike delivers at a very high price.

In terms of resource utilization, it doesn't seem like a good use of time/money to obsess over each bug as if it were an atypical event in a slow moving enviornment. But hey if it gets a few people at the top to start caring about security, maybe there is some value... I just hope it doesn't result in execs nagging the infosec team for updates on 'venom' and disrupting their work on real security measures for the company by focusing on the latest hot topic.

So many times have I tried to push things forward (internal system upgrades, new security policies, etc) that did not have any immediate impact but then something happens and we have to scramble together.

Being able to show this to a non-technical person and have them at least somewhat understand that there is a problem that needs to be addressed is invaluable.

I personally don't like the trend for the same reason why I dislike terminology like "ninja" or "rockstar" or "badass" or "devops". It cheapens computer science/engineering into resembling something a bunch of hip middle schoolers yammer on about alongside their video games and their skateboards instead of the multi-billion-dollar professional field it actually is.

The added design here seems a waste of effort and not really adapted to the targeted audience.

EDIT: The xen advisory gives you all the info you need in a couple of block of text: http://xenbits.xen.org/xsa/advisory-133.html

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.

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.

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.

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 least heartbleed and shellshock were kinda properly named, this one is a hell of a stretch.

Inb4 people start registering silly domains that can be used to spell out vulnerabilities.

CITRUS: Channel Insecure Transport Releases User Sessions

TBONE: Transmission Buffer Overflow Network Exploitation

BUTTER: Buffer Underrun Transactional Execution Relay

Let the parking wars begin!

For managing virtual machines, it's more surprising that we give VMs VGA devices rather than just using serial: when using VGA emulation, you cannot trivially write code that reads text on the VM's screen, but if you configure the VM to use a serial console, you can trivially write a program which controls the VM. In a libvirt-managed qemu environment when the OS has its serial console enabled, you can run "virsh console MyVM" and instantly start executing commands and parsing their output. You can also have the OS write its log to serial so that if the OS crashes you can still read the full log. When all else fails, serial still works. Additionally, a virtual VGA device has an infinitely larger attack surface than a serial device.

When doing unattended windows installs, a lot of people use floppy drives to store the Autounattend.xml file. Floppy disk images are the most trivial and smallest images for automation tools to create. They're additionally useful for placing a linux bootloader on to boot a linux install CD with command line parameters.

Most people still use CD-ROM images to install operating systems, and it's basically required for windows. Virtual machine management software also tends to use the cd drive to install guest tools since it's the easiest way to let the guest see large files from outside the VM - nearly every OS can read CDs.

http://www.xenproject.org/security-policy.html

----------

Public hosting providers;

Large-scale organisational users of Xen;

Vendors of Xen-based systems;

Distributors of operating systems with Xen support.

Here "provider", "vendor", and "distributor" is meant to include anyone who is making a genuine service, available to the public, whether for a fee or gratis. For projects providing a service for a fee, the rule of thumb of "genuine" is that you are offering services which people are purchasing. For gratis projects, the rule of thumb for "genuine" is measured in terms of the amount of time committed to providing the service. For instance, a software project which has 2-3 active developers, each of whom spend 3-4 hours per week doing development, is very likely to be accepted; whereas a project with a single developer who spends a few hours a month will most likey be rejected.

----------

Basically, if you provide a service to the public which uses Xen (Not restricted on size), or use Xen at large scale internally, you can get on the list. There are several small hosting providers that utilize Xen on that list.

Presumably if you use Xen at small scale internally you're less worried about security vulnerabilities as it is only your employees with root access to the machines - if external users have root access, you probably fall under one of the other definitions.

On the Rackspace public cloud I've been through three full-fleet reboot cycles so far. Only one of those affected AWS customers, and AWS handled it in such a way that only a portion of their fleet was affected.

How could AWS do this when Rackspace and others couldn't?

For one, they could stratify guest placement based on instance type and guest OS. (Which I hear they do.) Most recent XSAs have only affected PV or HVM guests, not both. If you keep PV and HVM guests separate ...

AWS seems to be an example of good engineering, not an example of the perils of capitalism.

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?

Profit and PR are hardly the goal here -- community awareness and public safety are paramount. Vulnerabilities need to be obviated to the general populace at large.