Preferences

Amazon states that AWS is not vulnerable, no details but presumably they patched before the public disclosure.

https://aws.amazon.com/security/security-bulletins/XSA_Secur...


cesarb
Or perhaps they're using a custom-compiled Xen without the vulnerable floppy disk emulation.
More likely this. AWS has at numerous talks mentioned a slightly franken-xen fork of Xen.
drzaiusapelord
I'm guessing this. Why even make floppy emulation available? It has no use cases on AWS. Floppy support only exists really for Windows driver install at install time, if you can't slipstream the driver in. They probably tore out a lot of stuff while developing the EC2 infrastructure.
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.

cthalupa
You do not have to be a large company to get on the Xen pre-disclosure list.

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.

oasisbob
Or, AWS takes steps to mitigate their exposure, regardless of whether or not they receive embargoed disclosures.

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.

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

res0nat0r
I think it is even simpler than that: The big companies that have thousands of customers doing millions of dollars of business on hundreds of thousands of machines need more time to patch because their is much more money / business to be lost. Not giving large companies time to patch would do more harm than good in the end.

It is fundamentally unfair, and is perfectly reasonable.

oldmanjay
Why, might I ask, is fairness required? I'll stipulate that you're correct about said fairness although I could dispute that pretty easily
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.
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.
It is a necessary evil, no need for the rhetoric.

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.

duaneb
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.
As long as those friends don't misuse the information (spreading it to blackhats), what's the difference? If it's "hell" for everyone else on day N, it would be "hell" for everyone on day 0.
As other people mentioned, it seems more likely that they're running a Xen fork or have some other mitigation. The redhat notes state that once the host is patched, the VMs need to be shut down for it to take effect: https://rhn.redhat.com/errata/RHSA-2015-0998.html
The vulnerability is in floppy drive emulator code. It isn't clear to me whether all users are vulnerable or only hosts that have floppy drive devices defined [in their guests] are vulnerable.

If the latter, perhaps Amazon was never vulnerable anyway?

brohee OP
The disclosure states that due to another bug, even floppy less hosts were vulnerable...
mhayden
The exploit affects VM's whether or not they have a floppy controller or disk attached.
duaneb
If I were amazon, I would have done an audit of the hyperv software and removed the floppy driver code entirely if unused for precisely this reason. This strikes me as a basic, "no-brainer" hardening step for my billion dollar(s) hosting business.
They use Xen, not Hyper-V and yes they already remove/replace large portions of Xen.
justincormack
Their PV domains are not affected anyway. Quite possibly they are running qemu in stub domains for HVM as well, rather than on dom0, but you may well be right about the floppy code too.
jeswin
It would have been reassuring if they disclosed whether they were vulnerable earlier, and if it required a patch to be installed.

This item has no comments currently.