Researchers from MIT and UC San Diego recently demonstrated an attack against Amazon’s EC2 where an attack virtual machine can launch attacks against a victim virtual machine that is located on the same physical server. The paper describing this attack will be presented at ACM’s cloud security workshop next week in Chicago.
This is an attack against virtual computing resources, not necessarily against EC2 per se. In fact, this attack can potentially work against any virtual infrastructure, private cloud included.
Does this mean that there is a security vulnerability within EC2? Yes.
Should you be concerned? Not really.
To understand how this attack works, we need to first describe how virtual infrastructure works. A virtual “computer” is an abstraction that maps processes (computing tasks) to physical resources (CPU cycles, OS, and memory). When you are using a virtual computer, you typically don’t know on which physical server your virtual computer is located. This is one of the fundamental concepts that allows cloud computing to deliver benefits such as dynamic scaling.
Now on to the actual attack itself: the researchers demonstrated that because EC2, with a larger than random probability, may allocate virtual machines that launched in similar time frame onto the same physical server. The researchers took advantage of this fact and demonstrated that they were able to, with a reasonable number of tries, start a virtual machine on the same physical server that houses the target victim’s virtual machine. They call this process “cartography”.
One possible consequence of this is that the attack machine can starve the victim machine of physical resources—a denial of service attack. This is especially bad if the attacker knows that the victim is in need of critical access to resources—think code release time. Denial-of-service would come handy in an espionage attack.
Another outcome might be that by observing the fluctuation in resource consumption, the attacker can obtain sensitive intelligence of the victim. Think Disney and Dream Works host their animation renderings on the same physical server (which they will never do, by the way) and try to hide from each other their respective release dates. A spike in resource consumption by Dream Works may indicate to Disney that the former is close to their release date (therefore accessing their rendering more frequently). This is so-called side channel attack. A famous real world example of side channel information leak is the “pizza index” incident in Washington D.C.: The L.A. Times reported that CIA set the single-night record for pizza delivery on August 1st, 1990, the night before Iraq invaded Kuwait. Anyone who was observing the pizza delivery index (and knowing they are going to CIA) could conclude that a major International political event was about to happen.
But why is this NOT an attack that you should be concerned about? For this attack to be feasible, certain conditions must be true a priori. These conditions include that the attacker has knowledge of when the victim virtual machines would be launched. Some of these conditions, though not entirely impossible, are on the impractical side. While the author concedes that it is possible that an espionage attack with high-valued stakes may very well undertake such a method, it is hardly a concern for run-of-the-mill computing tasks running in EC2.
How can EC2 (or other cloud providers) protect themselves against this attack? The answer is simple—namely making the virtual machine placement process as close to random as possible. If you have N servers, a random process would mean that a virtual machine has 1/N probability to be placed on any particular server. As a result, the probability that an attacker virtual machine is placed on the same server as a victim machine is 1/(N2). If N is sufficiently large, this probability will be pretty small. As we last checked, EC2 has close to 40,000 servers. Consequently, 1/(N2) is 6.25×10-10, which is less than 2-30. This is not impossible, but will make the cartography attack significantly harder and a lot more expensive to launch. I should add that in practice you don’t need true randomness—adding a little bit of randomness would go long ways.
Another possible but highly impractical countermeasure is for EC2 to periodically remapping virtual machines. This method is akin to “proactive secret sharing” where each share of the secret is only valid within the current epoch—at the end of an epoch, the shares are regenerated and re-distributed. Here the virtual machine placement would last only as long as the current epoch and it is dynamically replaced to a different physical server at the end of the epoch.
Of course, these countermeasures will break some of the features that EC2 offers, such as being able to specify the IP range for your virtual machine. In addition, they will add considerable complexity to EC2 operations.
Summary. Virtual infrastructure has become the backbone of cloud computing, particularly in the area of infrastructure-as-a-service, whereby the provider supplies virtual resources on a pay-per-use basis. Security of the data/applications hosted has everything to do with security within the virtual infrastructure. What does this mean? Providers of IAAS must take extreme care when it comes to security and privacy of their operations, or risk facing far-reaching consequences.
Here at Forrester, I’m starting a study to investigate the security and privacy practices of leading cloud providers. I’ve identified Salesforce, Google, Microsoft, and Amazon as the four vendors that I would study initially. I have yet to make Amazon commit to an interview, but the former three have all expressed willingness to participate in this study. I will write more as the study gets underway. Until then stay tuned and let me know what you think …
A shortened version of this post can be found on Forrester’s security team blog: http://blogs.forrester.com/srm