[shaggy]

A vulnerability/exploit like this was only a matter of time. With cloud computing getting ever more popular I think it's only a matter of time before something like this causes a complete and total outage for EC2 or Rackspace or $Cloud_Provider. Security in the virtualization space should be focused on stuff like this because everything else can be addressed with traditional methods.

[tptacek]

Two issues that I think will matter more to cloud app platforms than VM breakouts (am interested to see how wrong I'll be proven here):

* Web app vulnerabilities in the control plane (management tools, monitoring, API).

* Cryptographic vulnerabilities stemming from crypto code running on the same hardware as malicious attackers, or within nanoseconds-precision measurement range on the same network.

[dfc]

Do you think there is anything "cloud specific"[1] about the web app vulns in the control plane? Or is this just the bread and butter targeting of command and control?

Cloud computing certainly opens up a plethora of side channel attacks that probably would not have been possible before.

[1] Its unfortunate that this is such a loosely defined term. I am not trying to be fussy and overly pedantic.

[tptacek]

Yes: the control plane infrastructure for cloud providers is (a) usually sole-sourced to the cloud provider, (b) usually custom-build, (c) often ad-hoc, and (d) virtually always multi-tenant.

[dfc]

I think (d) is the compelling answer. I'm not sure I think that (a-c) are really all that unique to cloud environments. The same can be said for a lot of niche and/or legacy environments dominated by one or two firms.

The side channel prediction is really interesting.(1) Do you think that capability will become widely dispersed or only the realm of the Advanced Persistent Attacker (or whatever the buzznym is)?

(1) Not to imply that the C2 prediction is boring/lacking merit.

[patio11]

An example of the attack Thomas is talking about: Rails and Django were both bitten earlier last year (?) because their session cookies used HMACs to avoid tampering. Those HMACs were compared against the expected ones using the == operator, which short circuits in Ruby/Python, causing the comparison to be timeable.

Over the Internet, this is a problem. Over the intranet, this is a You Can Own Someone's Admin Cookie In 30 Minutes With A Nearly Trivial Ruby Script, because the timing attack is orders of magnitude easier. (You get nanosecond precision in measurements using only thousands of probe requests.)

The cloud angle to this is that deploying on Heroku / Slicehost / EC2 / etc would let the attacker, for the price of a stolen credit card (or less!), trivially get a local network vantage point from which to attack your application.

[yuhong]

It is not a VM breakout. Just causes a escalation to ring 0 within the VM.

[tptacek]

Not that VM breakouts aren't a serious concern, because they obviously happen too. (Sorry for the pedantry).

[zackattack]

I find "the pedantry" wonderfully informative. :)