CS 739 Review Blog

Summary
--------
The paper reveals the security vulnerabilities possible in a cloud, by exploiting the fact that physical shared resources can lead to several side-channel attacks. It presents the case study of Amazon EC2 and shows that it is economically feasible to successfully plant attacks.

There are two steps in such an attack - placement and extraction. To be able to attack a victim, an attacker needs to achieve placement on the same physical machine as the attacker. By carefully studying various created instances in EC2 based on zone and type, the paper shows that it is possible to identify the zone and type of a victim instance based on its IP address prefix. Once we know the zone and type of the victim, the attacker can try to create a VM of the same zone and type. This places attacker's VM very near a victim. However, placement near a victim is not good enough. We need placement on exact physical machine as the victim. By using a simple set of heuristics, paper shows that it is possible to achieve that. This placement can be confirmed by simple tests such as by creating a hard-disk-based covert channel. To achieve placement, we can use a brute-force strategy of creating new VMs till we succeed(which is good enough) or we can smartly utilize the placement locality of newly created VMs.

Once the placement is done, the attacker can plan several attacks. Attacker can monitor the cache usage of the victim. The cache-based side channel has been shown to reveal information such as cryptographic keys. The attacker can also do efficient co-residence detection based on load, start estimating the popularity of the victim and can also plant a keystroke timing attack. However, these attacks are made difficult by the fact that there may be other VMs sharing a machine apart from the attacker and the victim.

Only good way indicated in the paper to solve these problems is to avoid side channels, and allow clients which have sensitive data to exclusively allocate physical machines to their VMs.

Problem Description
--------------------
Cloud providers place VMs of different users on the same physical hardware, to achieve efficiency and hence offer cheaper services to users. However, this has the side-effect of compromising the security of users' data.

Contributions:-
--------------
1) Brings out the security loophole in the cloud, and a possible solution to avoid this.
2) Use of different side-channels to extract information is interesting.
3) Reveals the placement policies of Amazon EC2 cloud.

Relevance/Comments:-
-------------------
With cloud services being highly popular, the paper provides a word of caution to the cloud users and the providers alike. I think the paper is very relevant at this point and it might bring about security guarantees in the cloud services of the future.

It is amazing how hackers gather so much information out of totally meaning-less data.

Summary:
Using the Amazon EC2 services as a case study, this paper explores the non-obvious vulnerabilities in third-party cloud computing services. It shows that it is possible to place the malicious VM on the same physical machine as the target user, and then extract confidential information via a cross-VM attack.

Problem Description:
Recently the third-party cloud computing services have become more and more popular. This kind of services can provide advantages like economies of scale, dynamic provisioning, etc. However, it can also introduce risks.
In such services, different users can share one physical server and they trust the service provider. The authors of this paper aims at finding out:
-Is it possible to target a user, and then get confidential information from the user, taking advantage of the shared physical resources?
-If this is possible, what actions should be taken to achieve these attacks?
This paper focused on Amazon EC2, but the studies and results can also be applied to other similar services.

Contributions:
It is natural to consider possible information leakage across VMs through side-channels under the environment of third-party cloud computing services. However, this paper seems to precede in such kind of research. It raises up the potential security problems in third-party cloud computing services and does a practical case study on Amazon EC2.
It models the steps to achieve information leakage: cloud cartography, determining co-residence, exploiting placement in EC2, and finally information leakage. These steps are external, without any technical details disclosed by the provider.
The techniques used in this paper are not theoretically complicated, but are quite practical. The experimental results have shown that co-residence with the target and cross-VM attacks are possible.

Applications:
In the positive perspective, this paper provides lessons and hints for the service providers in the system building, service setting and customer protecting.

This is essentially a 'hacker paper' discussing multiple ways to leak information between mutually distrustful users on a shared cloud infrastructure. The primary conclusion is that there are multiple ways to thwart information leakage in the cloud, but the best is to avoid co-residence on a physical machine between distrustful users.

The problem presented in this paper is two fold. First, it is possible to learn about the inner details of the cloud and probable to place an adversarial VM on the same physical hardware as a target VM. It is also possible for co-residing VMs to use side-channel attacks to gather information about another VM.

The authors tried many different approaches for discovering the cartography of the cloud and performing side channel attacks. In addition to the two claims made in the problem statement, the contributions of this work include:
1)Network probing is used to discover cloud cartography
2)Some internals of EC2 are discovered including the internal IP address partitioning between availability zones and how IP addresses were observed to be static.
3)Presented three methods for determining co-residence of co-residing VMs. (Including the Dom0 IP co-residence check with a false positive rate of 0).
4)Suggestions on obfuscating co-residence through network configurations
5)Adapted Prime+Trigger+Probe cache measurement to make a more reliable and efficient cross-VM covert channel.
6)Made a keystroke timing attack without a network tap but using the cache-based load measurements.

The cloud is 'computing as a service'. The concepts in this paper can easily be applied to other service-oriented systems. Any system that allows a user to learn about the inner details of the service or to share physical resources with an untrusted user may be at risk.

Consider cell phone networks. Towers are shared between various users. Is it possible for a cell phone to detect tower or network load through timing or other means? In the world of privacy considerations, people are often concerned about not publishing their current location. Their use of these infrastructure services may reveal their location in one way or another (though, perhaps this can be thwarted by encryption and many users using the same physical infrastructure).

In the case of the power grid, it is often easy to tell if somebody is at home or not by observing the power meter outside of their home. There are many other scenarios were unintentional information leakage may occur.

This paper focuses on the data safety concerns in running VMs within a cloud computing highly virtualized infrastructure. Cloud topology can be acquired by probing the network. The authors try to think in a hacker’s way to find the ways how information may be leaked and give an alert to others to arouse higher attention.

Cloud computing has highly virtualized infrastructure. It is common for people think that running VMs in one physical machine is safe and separate. However, this may not be true. Authors need to consider very completely as real attacks can enter at any covert channel with enough bandwidth between two VMs, which is easily established in many simple ways. One good side of this paper is that it focuses on safety concerns of the basic infrastructure design. The problem this paper trying to discuss and solve is how to find out the state of physical machines and co-residence VMs. Many methods can be used to calculate and guess the topology of the internet.

The authors point out the the VMs are not as safe and separate as we thought. If they can use many existing methods to figure out some states information of physical machines and co-resident VMs, attacks may also acquire the information in the same way. Probing by using some network tools and statistical approach helps to get the cloud’s operation policy. As we know that VMs in the same machines still share the same physical internet link, storage and other resources, the information leakage caused by sharing the same resources is hard to be avoided even the infrastructure of the cloud computing is highly virtualized. The authors also proposed some solutions. We can try to make resource allocation to be coarse-grained. This will increase the difficulty for attacks to guess from the sharing resources. Meanwhile, fully separated the VMs may also be a solution. Each VMM needs to clear its footprints thus prevents information leakage. Also we can turn to hardware for help, but this costs a lot.

This topic is very interesting and necessary. I am not quite sure whether the solutions or ideas really work as there are so many assumptioins. But I think it is important to realize that this kind of hidden trouble is existing and we need to take some actions.

Summarization:

This paper demonstrated that by exploiting the shared nature of cloud computing, a valid malicious VM instance can steal valuable information from other VM instances

Problem Description:

Cloud computing has become a buzz word. Many big companies are offering cloud computing service. How to make sure that the confidentiality of the client is not breached is important. This paper has shown that by using various techniques, much information can be leaked from one VM instance to the other.

Contributions:

(1) This paper has shown that it is very conceivable(and also practical) to purposely mount one malicious VM instance with a victim VM instance on the same physical machine.

(2) Topology of the network can be easily obtained by measuring the network response time.

(3) Once the scheduling policy of the cloud computing service is extracted, plus the co-residence of attacker and victim, various known techniques can be leveraged to launch attack, mainly side-channel attack. One particular attack mentioned in this paper is Prime+Trigger+Probe attack. Such attack will infer knowledge from the key-stroke, cache, load-balancing information. Various existent techniques can further use such information to infer something more valuable,

Applicability/Comment:

In data security research, people are concerned about CIA(Confidentiality, Integrity and Availability). This paper mainly deals with Confidentiality. This paper also deals with availability issue when talking about how DOS attack can be initiated in the cloud computing. And it has demonstrated that in a real world appplication -- Amazon's EC2 cloud computing service, by investing very little, a malicious client can extract much information. Although the reported cases only show that coarse grained information can be stolen, it however indicates that by using more advanced techniques, those coarse grained information can be translated to something very useful, such like private keys. Furthermore the author believes this is not just Amazon's problem, but fundamental to all the other cloud computing services.

Problem Description:
The paper tries to expose the data security vulnerability present in outsourcing the data and computing onto the cloud infrastructure. Of all the other threats that can be possible, the paper discusses only about side channels, cross-VM information leakage that can occur due to sharing of physical resources.

Summary:
The paper presents the several vulnerabilities present in outsourcing to the cloud and focusses on cross-VM information leakage. The paper first analyses the pattern of the mapping of the instances to the machines based on zone and type and then analyses techniques to determine co-residence of victim and adversary and then discusses the strategy in exploiting the placement strategy to achieve co-residence. It discusses several ways to attack the victim to read the information. The paper also discusses the technique to avoid the co-residence based attacks. By this the paper shows an attacker can exploit the placement strategy to stealthily co-reside and fetch data from a victim.

Contributions:
There are several contributions that I found interesting in this paper.
1) Listing out all the possible data security vulenerabilities that are present in the cloud.
2) Discussing how to achieve cloud cartography
3) Presenting how to determine whether the attacker and the victim are co-resident
4) The technique used for communicating 1's and 0's across VM using read.

Applicability and Comments:
As data security is one of the major issue that prevents people from using the cloud, this paper is a really good eye opener that shows the problems with virtualization. I am doubtful about the 40% rate of success in achieving co-residence. Also the solution was so simple and I was able to guess it at the very begining.

Problem summary and description:
Offering virtual machines as a service in a cloud computing platform has become a viable model these days, and companys like Amazon are offering such services (EC2). Although this model has inherent advantages such as scalability, some aspects of the model have not been studied yet. One such aspect is the security threat posed by running a customer's application in the cloud. It is already known that the company offering the virtual machine service must be trusted. However, it is not well understood whether third-parties can affect the security of a virtual machine in this model. The paper tries to evaluate the security provided by the model when the adversary can act as a normal customer of the company providing the service.

The method described in the paper is as follows:
1. Try to determine the physical host where the virtual machine of the target is placed.
2. Try to create a virtual machine instance which will be located in the same physical machine as the target's.
3. Utilize cross-VM channels/exploits to gain sensitive information from the target's VM.

The paper uses Amazon's EC2 as an example for a cloud service offering and demonstrates attacks in it.

Contributions of the paper:
1. "Cloud cartography" - a method which might be used to determine how IP address of the VM can map on to the "type" of the target VM in the cloud.
2. Methods to determine whether two VMs are co-located in the same physical host in EC2.
3. Methods to co-locate a VM in the same physical host as another VM.
4. Many methods which can affect the security of a VM which is co-located with the attacker's VM.
5. Although it does not go into detail, the paper also mentions how such attacks can be prevented (essentially by not sharing physical hosts between VMs of different customers).

Applications and comments:
The paper makes an interesting read. It is baffling to find out that adversaries have a 40% success rate for co-locating their VM's with a target's VM. It will be interesting to know what methods were invoked by Amazon and EC2 customers for preventing the security flaws described in the paper (if there are any such methods yet - the paper is a recent one). On the other hand, do people really out-source security-sensitive applications to the cloud as is described in the paper? It would be interesting to have statistics on that too.

In this paper, the authors discuss and provide experimental evidence that information can be leaked in the cloud between separate virtual machines. They use Amazon's EC2 as their testing cloud. In their experiments they are able to create a map of the internal cloud infrastructure, locate where a particular VM is likely to be placed, determine if they are co-resident with the selected VM, and continue launching new VMs until one is co-resident with the targeted VM. The threat model they use has adversaries are non-provider-affiliated malicious users and the victims are running confidential information in the cloud. In addition to having a cute title (yay Stones), this paper presents experimental results for mapping the cloud, determining co-residence, coercing co-residence, and stealing information from a co-resident VM. Their experiments on coercing co-residence are very interesting. In most of the experiments they were able to become co-resident with almost 50% of the machines they were targeting. The machines they were not able to achieve co-residency with were likely to be on machines with heavy load or machines that were full.

This research is very important. Security in the cloud is of major concern at present. With computing switching more towards a model that takes advantage of the cloud, users and businesses need to know that their data is safe or no one will move their data into the cloud. This paper shows that a clever malicious user can indeed steal information from other users in the same cloud. Fortunately the paper also provides some suggestions for how to tighten security to stop the types of attacks they performed. This problem, like other security problems, will never really be solved because there is always the potential for a malicious user to find another exploit or another way in. However, this is a good step towards addressing security in the cloud.

The paper talks about security concerns that arise out of using the cloud infrastructure for outsourcing computation. Cloud computing is becoming more popular given the advantages of a low capital, on-demand scalability and high availability. Some cloud providers like Amazon EC2, allow their users to load virtual machines on their infrastructure on demand. This paper looks particularly into the security threats that arise out of using VMs.

The authors suggest two main phases in the threat model they provide. The first is to make the location of different VM instances belonging to different customers and computations to be on the same physical machine. This is because cloud providers maximise the usage of their resources by multiplexing the available hardware among all of its customers. The second step is using this co-location and exploiting the various side-channel VM vulnerabilities to gain access to the private information of the victim customer. The authors talk about various strategies they used to achieve co-location and go further in stating that the options exported by the cloud provider makes it easier for an attacker to achieve the same. They attempt to map the cloud to the services running in it.

The cloud is trusted by third-party users for their computation. This highlights the importance of the security measures taken by the cloud providers to protect their customers' data. This paper presented an interesting read about one of the attack strategies. I remember there was a talk recently where the speaker proposed that the energy consumption of the cloud could potentially give off hints regarding the service using it. It would be interesting to know other kinds of side-channel attacks that can target the cloud infrastructure.

Summary:
This paper explores the new security vulnerabilities that cloud computing introduces, namely the ability of an adversary to execute on a VM that is on the same physical machine as a target machine. Once this co-tenancy is achieved, various known side channel attacks are used to gain information.

I think this paper is of main interest to small and medium sized businesses. Any large business worth their salt will not out-source their confidential data and execution to a cloud infrastructure provider. Even if they do so, they have the money to ask for dedicated machines so that they can avoid this problem. SMBs on the other hand will not be able to do so.

Problem:
The problem is that given cloud computing's relative anonymity in where your VM is going to run, it is assumed that finding the exact machine where your VM executes is difficult. The authors show that this assumption is not true, and use several techniques to map IP address to EC2 internal machines. The second problem is, how do you determine/force co-tenancy? The authors again provide ways to do this. Once these 2 problems are solved, normal covert channels attacks are used to gain information about a previously "anonymous and secure" VM.

Contribution:
The paper makes several useful contributions - the largest contribution is exposing that such a vulnerability exists, with concrete evidence for the same. The authors also provide techniques for mapping the address space of Amazon's EC2 service, and ways to confirm co-tenancy and do side-channel attacks once co-tenancy is confirmed. As it is, they build up a step-by-step attack guide.

Even though the use of such attacks seem unlikely ( provided the cloud cartography is avoided ), I believe there is value in thinking about the possibilities - It is quite possible that this paper will spawn new research in cryptographic and security areas focussed on the cloud, and such research will only be beneficial. Any idea which allows present day economies while retaining efficiency will go a long way in adoption of cloud computing by the big guys.

Comments:
Rather than dedicate a machine to each customer VM, I am wondering about the efficiency of running "cover" VMs throughout the cloud - VMs which would be started randomly at various machines throughout the cloud, and whose only purpose to perform activity which is likely to throw off known side-channel attacks. The placement of such cover VMs could be based on idle CPU and other such constraints.

From the other candidate talk that was presented recently, encryption of data on the cloud also seems like a valid way to prevent such attacks.

It is interesting that the problem arises more from business decisions than any real technical failures - If the cloud provider simply refused to provide co-tenancy, or exported the choice to the user ( Do you want your VM to share a physical machine with other VMs? ), much of the problem would simply go away. Live migration is also another good alternative to handle these attacks.

The paper presents a threat model for data security on clouds where an adversary can successfully locate specific victim instances and steal confidential information. The main steps involved in the attacks are first locate the victim instances, try to colocate one of your own instances with that of the victim, and then finally steal the information through a cross-VM attack.

The problem tackled by the paper is that with the increasing popularity of clouds by some massive and highly trusted corporations, it is easy to ignore novel threats to ones applications running on these clouds. This paper tries to introduce one such attack and provides suggestions on how to minimize risks from these threats.

The first step in the attack is that of successfully identifying the location of the victim instances within the cloud. This paper uses EC2 as the test environment throughout. By using the internal DNS service of EC2, the attackers are able to map the external IP addresses of the victim to its internal addresses. Also they recognize that the internal IP addresses on EC2 are partitioned regularly into availability zones and eaxh zone also is fairly uniform in the type of instances available in that zone. Thus this already reveals what sort of instances the victims have rented. The next step is to check if one of your own instances is colocated with the victim and the best method seems to be to check if both have the same Control-VM i.e by checking if the Dom0 VM on thier physical host have the same IP addresses which means that both share the same Dom0 and hence the same physical host. Finally to improve ones chances of getting an instance assigned to the same host as a victims instance, strategies can range from brute-force which will be more expensive to using the options provided by EC2 in requesting for instances types and availability zones to incerase probability of a hit. Finally the attack itself can range from simple attempts at DNS to infering other potentially confidential information such as utilization statistics of the victim instance to more complex attacks like keystroke logging by nticing the minute changes in cache loads on the host.

While the paper is definitely interesting, I find it very hard to believe many of these attacks are achievable and how they will be useful once mounted. For example, the keystroke logging concept, while I dont completely understand the mechanism, still seems to forget that these applications running on the cloud will always be accessed remotely and infrequently thus taking into account network latencies and other issues, the accuracy of the password recovery algorithms can be very low. While security is definitely an important consideration on the cloud, it is hard to believe that any company would put highly confidential information in a third party service however trustworthy the provider may be.

Summarization:
This paper proposed and experimented a variety of methods to access unauthorized data running on a victim VM within third-party cloud computing infrastructure. By probing the network, doing DNS lookup and guessing according to experiences, an undisclosed cloud topology could be acquired. By calculating round-trip time and using simple heuristic method, co-residence information could be detected. By issuing large amount of requests or controlling the time to issue these requests, there is even a high chance that a malicious VM could select a particular victim VM. Finally, by leveraging a Prime+Trigger+Probe measurement, leaked information could be successfully acquired.

Problem Description:
The problem this paper tries to solve is to find ways to “steal” information from other VMs running on the same physical machine within a commercialized cloud infrastructure. In fact, before this paper, the security concerns of cloud mainly focus on the provider’s integrity; this paper pointed out that even for trusted provider and infrastructure, there are still threats of getting unauthorized information by purposefully putting a malicious VM running on the same hardware as the target VM, and doing cross-VM side-channels attacks. Therefore, this paper is the first to shift the focus from provider’s policy to the more fundamental infrastructure.

Contributions:
First, this paper proposed an important idea that VMs in the cloud are actually not fully separated and safe. There are easy ways to detect the topology of the cloud infrastructure, to detect if two VMs co-reside on the same physical machine, and even to place one instance on the same physical machine with another instance with high probabilities. The co-residence of two untrusted VMs imposes new security vulnerability for information leakage. The alert of such vulnerability is the major contribution of this paper.

Second, the author showed the possibility of leveraging existing network tools and statistical analysis to guess the operation policy of the cloud. For example, by tracing the route of an internal packet, the IP address of Dom0 could be easily achieved; by calculating the round trip time of a small packet, co-residence information could be acquired; by issuing large amount of jobs simultaneously, even the cloud deployment policy could be guessed. This easy job of probing alerts the cloud company that hiding policies and topologies are as dangerous as, if not even more dangerous than, disclosing them directly.

Third, this paper also reminds us that VMs are not as separate as it seems to be. Since two VMs running on a single physical machine still shares the same physical resources, therefore, in the extreme situation, we cannot view them as running on different physical machines. This paper proposed several simple ways to establish a covert channel between two VMs, using Prime-Trigger-Probe measurement. Even such an un-optimized algorithm could achieve a bandwidth of approximately 0.2bps (in an extremely abnormal condition), making these methods possible for real attacks.

Real Applications/Other thoughts:
Although this paper mainly deals with Amazon’s EC2 cloud, this method could be generalized to other cloud providers with shared VMs running on a single machine. The difficulty of achieving valuable information (such as private keys, instead of the simple jobs shown in this paper), I have to admit, is high, but not infeasible. And the cost of such information leakage is huge. Therefore, we should still put much emphasis on this problem.

There might be several different approaches to address this problem, in addition to what the authors said in the paper. From the network prospective, a (at least partially) guessed topology is almost necessary for a practical attack; without a topology, probing will consume too much time. And a successful cloud cartography requires a dense range of IP addresses. Therefore, by deploying IPv6, where the space address is huge and existence IPs will be sparse, a network probing will be too expensive to carry out. From the cloud operation perspective, even simple obfuscation of network addresses or frequent migrations might greatly distress the attacker. From the user’s perspective, writing VM-safe code (keeping in mind that VM could leak information, so proper obfuscation is necessary) is an ideal and thorough solution.

Problem
The cloud computing has been very popular nowadays. The key service of cloud computing is ‘rental’ of virtual machines. These service rents a part of physical machine to multiple users into a form of ‘virtual machine’. In a virtual machine, the user has full access to ‘sand-boxed’ machine. However, current cloud computing provider uses ‘para-virtualization’ so the user could infer status of physical machine. From this fact, the paper poses possible security vulnerabilities of so called clod computing services.

Summary
The paper presents various ways to determine co-existence, host malicious virtual machine to target virtual machine and way to leak out information from target virtual machine. The key idea is that even though hypervisor tries to virtualize every possible resource, there are still window to peek into state of physical machine and ways to impact entire co-hosted VMs. The paper presents a way to exploit CPU cache. By actively flushing CPU caches, VM can guess what other VMs do. CPU clock is another good window to peek system-wide state. By measuring CPU clocks over simple operation, VM can also infer what other VMs do.

Contribution
The paper showed there is high chance of co-hosting. Co-hosting is an entrance to VM information leakage. Although some of assumption is unrealistic such as the hacker would need to know the exact deployment time, it showed plausible vulnerability overall.
It showed even well-managed, bug-free hypervisor is vulnerable to security threat. If we do not completely virtualize the entire system, which I think is not possible near future, it is always possible to leak out some information.

Applicability/Comment
I would doubt these leakage techniques are practical because leaked information does not have high value. Cache usage gives little information about target. I highly doubt what people could do with Keystroke timing attack. Also, some of these techniques could be easily fooled. If the system does not care about possible maximum performance, the operating system could take sleep between operations; it would confuse all kind of CPU related measurement technique described here.
I never thought about VM vulnerability but this paper showed it really is possible. Although current technique is not practical but just technical showcase, I could feel future is in danger.

Goal:
This paper presents various methods of that allow an attacker to place their VMs in the same physical machine as the victim VM in the Cloud. After achieving co-residence, it is possible to launch side channel to extract certain information from the victim.

Problem:
Virtual machine which is an important building block for many Cloud providers is believed to provide full isolation which prevents any kind of tampering between guest VMs. Thus, the Cloud is assumed to be a very secure environment.

Contribution:
The first step in co-residence is to map public IP addresses to internal one and onto the deployment options. This is possible because internal layout is quite static to reduce administrative overhead. This mapping allows an attacker to infer the parameters that can be use to launch VMs in the same region as the victim VM. Then, simple network technique can be use to determine if a specific VM is placed in the same machine as the victim VM or not.

After that, side channel attack can be launch from attacker VM to extract information from victim VM because they both share physical machine. The basic idea behind the covert channel communication is that a repeated operation on one VM will take longer time to complete if another VM is also using the same resource. Thus, it is possible to use cache or disk as a medium for this kind of communication. Although, it is not currently possible to extract important information such as cryptographic keys, it is possible to use this mechanism to infer about the victim VM activity which can act as a tool for future harmful technique.

Method to prevent these technique tends to increase overhead of administration or reduce system performance. Thus, the only viable solution right now is to allow the customer to pay extra cost for running their VMs separated from untrusted VMs.

Applicability:
This paper show that the Cloud which is believed to provide isolated environment is not as safe as people think it would be. Due to the fact that these datacenter can be treated as one big computer running untrusted code, we may find that some of the existing techniques that use within a single operating system can be applicable to the new environment of the Cloud.

Problem description and Summary:
Traditional attacks are prevented by using strong authentication framework. The advent of cloud computing, however, brings in new risks especially with a physical resource being shared across different users. The paper introduces a novel technique 'Cloud Cartography' to identify the configurations/locations of various physical resources and explains how this information can make web servers vulnerable to various attacks.

Cloud cartography is achieved by surveying public servers on EC2 using external probes. 'whois' is used to identify ip prefixes and wget for checking http content is being served. By using EC2 DNS servers, all private ip addresses used by the cloud are identified. This information can be used to identify zone of potential target machines. The next step is to identify trend in resource allocation by launching instances of varying types and generating a map from internal ip address to type. With the help of this map, an attacker can try to create instances of type similar to potential target and techniques like instance flooding, brute force placement can help the attacker schedule his VM on the same host as target. After verifying co-residence, the attacker can gather various statistics of target functioning or can even launch a DoS or various other side-channel attacks like stealing cryptographic keys and keystroke timing attack.

Solutions suggested:
The paper also presents various techniques to mitigate these attacks to some extent. First among them is to prevent cloud cartography by hiding infrastructure, or by isolating clients view of network using VLANs and bridging and probably disabling clients run nmap, hping like commands. It also suggests that inhibiting side-channel attacks is possible but incur high overhead and suggests that avoiding co-residence when possible is best alternative. But this may be expensive for cloud provider and eventually may end up charging users more for “private” clouds.

Contributions:
Cloud cartography: Exposing flaws of cloud environment by reverse engineering to decipher infrastructure of the cloud.

Exploiting placement locality: Identifying the patterns in resource allocation and flaws with techniques like serial/parallel placement locality used by cloud providers.

Relevance:
The paper definitely has important points to keep in mind for cloud providers. Especially, 40% success in obtaining co-residence is not good although the probability of side-channel attacks succeeding is low. Also, may be I am missing the background, some of the side-channel attacks like stealing cryptographic keys are not very clear. It would have been more useful if the approximate success rate of such attacks(from other sources cited) is mentioned.

"Hey, You, Get Off of My Cloud" describes different security vulnerabilities found in cloud computing and tries to measure the ability to exploit them. The measurements on Amazon EC2 indicate how devious workloads can glean information from victim VMs which in turn can result in a privacy breach. Similar exploits should be possible from other cloud providers, such as Microsoft Azure.

The problems identified by this paper is actually the main thrust of the piece. They ask what problems exist in running co-resident virtual machines in the cloud, how easy is it to exploit these vulnerabilities, and what can be done to the victim when their is an exploit. The secondary problem, and never fully explained here is what the cloud provider can do to protect the users if someone did want to attack using this approach. This is a problem that others will surely take up.

After the main problems are identified, the approach to getting the side channel attacks laid out is a main contribution. Measuring the results yields some interesting attributes to EC2 that might otherwise have gone unrealized. I feel like the prime-trigger-probe technique is crucial to getting information from another VM which is co-located. This work adds that technique, and measures the efficacy of using it effectively. I was impressed with the various threats they presented, though the measurements did not help them especially.

Applying this work to a real system makes sense in three ways. First, one could actually perform attacks on sites using some of the information here, though that would be be ill-advised. Secondly, the cloud providers can attempt to patch the holes that exist because of this attack to prevent user privacy being breached. Some of the recommendations state how a provider might adjust some things to be safer. Lastly, cloud users should be aware of these problems so that development can try to avoid being exploited, or at least keep private data out of the cloud or a safe, trusted area. Each of these applications of the paper could be reasonable.

This paper describes how side-channel attacks can operate in a cloud environment like Amazon's EC2. A complete exploit is at this point impossible, but the authors describe how it can happen and what can be done at each step to minimize the avenue for attack.

The first exploit is in the cloud cartography. This is made possible by Amazon's effort to simplify their allocation implementation. Memory paging uses large constant-sized chunks for simplicity, and Amazon is taking a similar approach. This uniformity makes it easier for adversaries to find themselves on the same machine as a victim.

The second set of exploits help determine if an adversary is on the same machine as a victim. If hosts have similar internal addresses or have short traceroute paths, it is very likely that they are on the same machine. This is another result of a decision for simplicity's sake.

The final set of exploits examine information leakage due to resource usage. The only exploit that seems realistic, and that the authors spent any real time on, is cache usage. Memory usage can be guessed based on how much the cache changes between VM context switches.

The problems arise because Amazon is choosing efficiency over fully emulating an independent machine. There are some simple remedies that should be applied. Network communications between two users should be routed outside EC2 before coming back in, thus preventing timing or traceroute attacks to discover locality.

The two full solutions are not exactly exciting. One solution is to make allocations more course-grained: a service could choose to be allocated only entire machines, thus missing much of the point of virtualized and scalable systems. The other solution is to fully separate all VMs; they should not be able to see anything going on in another node. The VMM would need to wipe the cache during each context switch, and do something similar for the rest of the resources that can be used for side-channel attacks: the Dutch boy with his finger in the dyke. Another possible solution could be more specialized hardware; that would either cost more than commodity hardware or a lot of time to be cost-effective.

There is nothing terribly tangible in these exploits, though. The course-grained scheduling of virtual machines makes it hard to discern much from other VMs. There's also much less certainty that you have found the system you are looking for. They are much more feasible if run as multiple processes in the same operating system, where resources are much more closely shared, and you are completely certain that you are running on the same system.

Though these exploits are not yet tangible, it would be ignorant to claim that they never will be. Any one of the three primary steps (mapping the cloud, determining co-residence, side-channel sniffing) could be improved at any time.

The emerging trend towards cloud computing has led authors to analyze the shadow side of this aspect. In author’s words this paper summarizes the vulnerabilities of cloud computing towards side channel attacks between virtual machines.

The paper explains Microsoft’s Azure cloud but primary focus is on Amazon’s EC2. Authors does not consider Azure to be a fully IaaS plateform. In EC2 users can choose region as well as availability zone along with selecting computational power, memory and persistent storage space. There is nmap, hping, and wget to identify public services alongwith external and internal probes. Infrastructure clouds are built on virtualization mechanisms. Virtualization allows for introspection into untrusted guest virtual machines. There is information gap i.e. how we can know that we are monitoring the right data and code. There is cloud cryptography mechanism. Availability zones are inferred by differences in IP addresses of different zones. The co-residence is checked by matching DomO IP address, small packet round trip time and close IP addresses. A combination of primr+triggering and probe acts as measuring utility for cache usage. Brute Force scheme and locality utilization strategy are analysed for making a probe VM co-resident with target VM, and later claims to provide much better success rate according to the paper.

Briefly saying, the paper describes how to attack a target virtual machine inside cloud in a series of steps i.e. map the cloud provider’s internal infrastructure alternatively known as cloud cryptography, identification of attack target position, placing a host virtual machine in same host of target virtual machine and finally performing side channel attacks leveraging the shared resources. Researchers worked on the fact that despite isolation that VMs are supposed to guarantee, attempts might be made to penetrate the isolation between VMs and violate customer confidentiality. So by the observation in present case it was concluded that anonymity by virtue of hiding in the clouds simply can not be considered as an adequate defence.

Though this paper presents the aspects in detail but still it remains questions that Are the side channels really effective. It is too important to analyze the distinct nature of security problem discussed by paper from the general security issues discussed by distributed system scholars. Also a number of the highlighted captions remain concepts and are not adequately exploited. But it is clear that security in clouds is more complex then originally envisaged. While there are great opportunities for cost cutting and access to practically limitless computing resources, a lot remains to be explored.

Problem :-
The practice of outsourcing computation and services to third party cloud services has become really popular these days. There is a need to explore and understand the security issues that arise in this new model in the interest of the cloud providers and their customers. These insights would provide valuable inputs to cloud providers in designing better cloud services and a greater sense of security to the clients.

Summary :-
The paper looks at the security threats arising in the EC2 cloud infrastructure scenario due to the vulnerabilities introduced by the co-location of VM instances belonging to different services on the same physical machine. The model used for the analysis assumes the provider and the infrastructure to be trusted and the other clients of the clouds service as potential adversaries. The paper discusses ways to achieve co-location with victim VMs and the vulnerabilities that can be potentially exploited by doing so.

Contribution :-
The paper provides fresh insights into the new security vulnerabilities in the cloud scenario. The paper explores the issue by actually trying out various strategies in the EC2 scenarios and providing an idea of the efficacy of these strategies compared to the brute force scenario. The paper also tries to map the EC2 cloud infrastructure for creating efficient co-location strategies and achieves reasonable success in doing so. It discusses ways to determine co-location and minimising the false positives in this process. It provides techniques to leak information about victim VMs after co-location using side-channels. It also discusses ways to address some of the problems presented in the paper and make it more difficult for adversaries to exploit the vulnerabilities.

Other comments :-
I really liked the paper in the way it presents the various security issues in the cloud. It seems that virtualisation still leaves some of the security issues unaddressed. I am wondering about the efficiency of using periodic VM migration as a means for mitigating some of the security issues discussed in the paper while not being an impractical solution.

Summary:
The cloud computing provides a virtualization platform for users to share physical resources and therefore reduce much cost. But such new technique on the other hand exposes users’ private data to third-party (the cloud provider) and it may also cause security problem because it shares physical media among different users, who may be malicious. This paper analyzes the security problems in cloud environment and provide their solutions.

Problem:
The security problem could be roughly divided into two types: 1) the malicious cloud provider 2) security between different user applications. This paper focus the latter because it is new problem caused by the cloud environment. The authors discuss several concrete questions in this aspect:
1. How to determine where an instance is located in the could.
2. How to identify two instances are co-resident on the same machine.
3. Whether an adversary launch instances will be co-resident with other user’s instance.
4. Whether an adversary can exploit cross-VM information leakage once co-resident.

Contributions:
Obviously, this paper gives some useful solutions about security consideration in cloud computing. More importantly, as I see is that it proposes several new and important security considerations in the cloud environment.

Questions/Comments:
Frankly speaking, I don’t very enjoy this kind of paper, which has a lot of assumptions. I prefer paper focusing on solid and real problems. Because the first question the system guys always ask is: dose it really work? This paper provides some new ideas, but lacks realistic evaluation.

Summary
The authors describe numerous techniques that may be used maliciously against others’ virtual machines in cloud computing environments. Recommendations are given on ways to mitigate or at least address these vulnerabilities.

Problem
Cloud computing platforms increase the “surface area” of potential attacks because it is possible that a malicious user’s virtual machine may be running on the same physical machine as a target’s virtual machine.

Contributions
The authors introduce a variety of malicious techniques, generally to determine co-residence of one’s own virtual machine with a target’s virtual machine. Co-residence can be determined with good probability by observing internal IP address assignments, traceroute, and networking timing. Side channel attacks exist too such as simultaneously generating load to a target virtual machine (e.g. HTTP GET requests) and observing CPU load. If a malicious user intentionally causes a spike in activity to a target’s virtual machine and notices a spike in CPU load on their own virtual machine at the same time, there is a high probability of co-residence.

Applicability
It’s hard for me to imagine just how much actual data can be extracted due to the extent of virtual machine isolation even when co-residence is known. Of course, I’m not a security expert so I may be entirely wrong. I think the authors’ conclusion is valid in that separate user’s virtual machines shouldn’t be co-scheduled (if requested). However, this sort of defeats the purpose of the cloud infrastructure in the first place. That is, cloud providers generally want to “rent” out spare CPU cycles/other resources instead of dedicate a physical machine to each cloud user.

The paper discusses about possible ways of side channel vulnerabilities being achieved in a cloud computing service. Since the cloud providers want to maximize the usage of the resources, it is being multiplexed among the customers of the cloud. This enables different services to share the same physical resources and in turn creates opportunities for side channel attacks. Though there are several other attacks possible like denial of service, this paper focusses on the possibilities of side channel attacks.

It is difficult to make the attack service to share the physical resource with the victim. The obstacles involved are the scheduling and the resource allocation policy followed by the cloud provider, the richness of the common services offered by the cloud provider (like DNS service which maps public ip to private ip), the time between the start of the victim and the attack service, the scale of the victim service (bigger service tend to occupy the entire physical resource rather than sharing with other services) etc.

The authors have made their experiment in Amazon's EC2 service. The initial phase tries to gather ideas about location of the target in the cloud space. Few methods are proposed like a brute force approach and by exploiting the placement locality to check the co-residence with the victim instance. The side channel attacks are launched once the co-residence is achieved. Finally few attacks are also illustrated using the attack. However the attacker has to pass through two stages to launch an attack. 1) The attack service must be made to share resource with victim. 2) Must be able to exploit side channel attack on victim. Thus solution to either of the stages can be further reduce the probablity of the attacker's success.

In a compromised stand-slone system, a single service is affected. Whereas in a cloud like environment, all the services hosted might get affected. The paper clearly brings about the security risks that are possible because of resource sharing which is the main trait of cloud computing. The results achieved are more through empirical analysis (somewhat similar to determining the amount of memory to overflow to overwrite the return address of the stack). But experiments of these kind are the only way to find information about a black box system (the policies/mechanism followed in the cloud) to exploit the loopholes in the system.

This paper exposes the vulnerabilities present in deploying the applications in a cloud computing environment such as Amazon Ec2. These vulnerabilities results from the ability of a third party intruder to manifest the VM placement at the same physical hardware infrastructure as that of target. After the intruder succeeds in co hosting the VM, the paper shows the potential information that could be extracted from the data caches that inherently shared between the VM's. Such information could enable extraction of RSA and AES keys.

The major contribution of this paper is the presentation of cloud cartography of Amazon EC2 through a set of network probing measurements. It then presents set of simple checks that could be performed by the intruder to determine the co-residence. This would enable to fine grain the location placement once a particular zone is selected based on the internal ip address of the target service provider. The attacker could enumerate the target list present on its home zone, in order to verify if it is co resident with any one of them.

Although the paper presents interesting techniques to tweak in a cloud computing infrastructure to extract certain infrastructure related to a target provider, yet the utilization of the data for an attack does not seem to be that clear from the discussion. It would have been interesting if the author presented some findings regarding the period of time that an instance resides in a same machine. It would be very well possible that although succeed in co-existence with the provider VM, yet the amount of data tapped in may not be sufficient if the provider migrates frequently. The denial of service attack seems to overlook the fact that cloud platform would migrate the provider to other machines on which there is no target instance.

Given that the paper mentions it is a 40% chance of achieving co residency with little over head it seems to be a good case of placement. However extracted information may not be utilized unless it is application specific. It would have been more interesting if the data from file buffers or other design vulnerabilities of virtual machine monitor could be utilized alongside to extract private information about the application.

Summary:
This paper explores the issues of privacy and security on Amazon’s EC2 cloud computing platform, and finds that applications are not secure. It is possible for one cloud application to determine the location of other applications and perform side-channel attacks to subvert their operation. Although the techniques are mostly well known, this paper explores them in the context of cloud computing for the first time.

Problem:
Cloud computing presents the promise of offloading computation to a “sea of computing resources” in a highly automated way. Amazon’s EC2 is one provider of cloud computing services. The issues of security for privacy-sensitive applications running on EC-2 is very important because applications storing medical and business applications are already being deployed, which makes this study very timely and it generates an important result; namely, that applications running in the EC-2 cloud are not secure.

Contributions:
The paper is very well written, assumes little about it’s audience, and is very descriptive. The authors clearly describe the steps through which a malicious application can gather information about other applications in the cloud. The information is obtained without using any exploits or subversive code. The treatment is very thorough, and the authors discuss a wide variety of types of information that can be obtained by a malicious application. The appendix also discusses the legal issues and ramifications of their work, which completes this very comprehensive work.

Applicability:
This paper has had a great impact on research in cloud computing security. Since this paper, many researchers, both theoretical and applied, have endeavored to enhance the security guarantees of cloud computing services. Complete security is still a long way off, and it may never happen, but nevertheless it is certainly valuable simply to know that information is not secure. This is the key result of this paper.

Summary:
This paper propose the security issue along with cloud computing. Ristenpart et al took Amazon EC2 as a case study of the potential vulnerability within the third-party compute clouds.

Problem:
The fundamental risks with public cloud computing arise from sharing physical resources between mutally distrustful users. The adversary is able to penetrate the isolation between VMs and violate other users’ confidentiality through cross-VM attacks.

Contribution:
Ristenpart et al investigates the possibilities of cross-VM attacking. They did case study on Amazon EC2 and explored the attacking methods in a cloud environment as follows:
- Co-residence checking: To make a certain attack, the adversary must launch its VM on the same physical machine on which the victim resides. The Network-based co-residence checks. The instances are co-resident if they have matching Dom0 IP, small packet round-trip times, or numerically close internal IP addresses. Based on the potential co-residence result, the veracity is verified via sending messages over a cross-VM covert channel. Based on the experiment with Amazon EC2, the author suggested that the cloud provider to obfuscate the co-residence by disabling the Dom0 to respond in traceroute, randomly assigning internal IP, and/or use virtual LANs to isolate accounts.
- Exploring Placement: Two ways of placement are introduced – Brute-forcing placement and Abusing Placement Locality. Per my understanding, the second one is kind of more efficient does better than burte-forcing for individual target or small target set.

Comment:
In the conclusion section of this paper, it says that “the best solution is simply to expose the risk and placement decision directly to users. A user might insist on using physical machines populated only with their own VMs and, in exchange, bare the opportunity cost of leaving some of these machines under-utilized.” – I would look this statement as a negative statement about the security of third-party cloud computing. What’s the difference between populating the physical machines with VMs from only one customer between the customers buying their own machines. Thus, I do not think Third-Party Compute Clouds will succeed in the high-end market. Instead, I have much expectation on the internal cloud, in which the service providers(e.g. VMWare, IBM) helps enterprise customers to build their own internal cloud.

An overview of different attacks, with complimentary defenses, against 3rd party cloud resource providers is given in this paper. Laid out is a case study against EC2 detailing cloud cartography, co-residency checks, vm placement, and information leakage.

Outsourcing your infrastructure needs to a cloud seems like a smart move: less to worry about, pay for what you need, and readily scalable. However there is a dark side and lurking within is the possibility of compromised security by how applications are allocated. The problem is your service is running on a machine with a malicious service. The sneaky devious service is collecting information because it's sharing physical hardware that can be monitored. Of course that is only one of a host of things that can be perpetrated against your service.

A number of clever ideas arise on how to use a seemingly limited venue to obtain all sorts of information and meta data. A virtual machine feels like an abstraction that utterly isolates an instance from anything else on a given machine, it's unsettling to see this isn't true. The cloud mapping via systematic probing is the most mundane but also most useful as the zones and instance sizes become an integral part of their analysis. My favorite notion is the subverted data transfer enacted through random disk writes and subsequent reads. Also note worthy is determining placement schemes and initiating malicious instances after hammering a target service to force it to grow.

I believe this paper has tremendous value as a look at how these systems can be exploited. Knowing what to defend against makes it easy to implement newer safer systems. However, I disagree with the notion of masking or hiding the internal network structure and placement policy as suggested in the conclusion. Security through obscurity is the worst model known to man and remember most breaches start from within anyway.

This paper analyzes the security risks involved in a cloud environment.

Cloud computing is emerging as a new paradigm for hosting data and the services.This paper explores the data confidentiality issues posed by the cloud architecture. The security threats for cloud applications can be broadly classified into two : 1) the traditional well known model of a malicious service provider violating the confidentiality. 2) A relatively less known model in which unrelated user applications seek to compromise the confidentiality. It is the latter that the paper focuses on. The reason this is even possible is because the applications running in VMs still share the underlying physical hardware and hence can avdersially manipulate the data caches,branch target buffers etc to victim's disadvantage.

In particular, the authors explore the Amazon's EC2 cloud computational services to analyze if the location of the victim applications can be established and if co-residence with such an application can be achieved. Surprisingly, this can be done using just the standard services provided by EC2. using a bunch of network programs, the authors were able to map the Amazon cloud infrastructure determining the availability zones or the instance types and the corresponding IP address ranges. EC2 follows regular placement algorithms : All the instances belonging to the same account ran on distinct physical machines. Sequential and Parallel placement locality ensure that programs run one after another or within short intervals of each other are likely to end up on the same physical machine. Armed with the cloud map and the placement algorithms, the authors were able to launch brute force attacks or a more sophisticated attack by simply launching the applications of the same type and zone as the target applications.Once co-residence is detected the attacker can launch side channel attacks say using the covert channels.

Some techniques for circumventing the attacks were also suggested. Obfuscating the internal cloud network is one of them. Another way is to allow the users to specify the details of their application's environment i.e a user may opt to run his application alone on the physical hardware at an extra cost. While this may go against the cloud computing philosophy of optimally utilizing the CPU cycles, it is a foolproof way of securing his data and computations.

The interesting part of the paper was that the authors were able to launch attacks by simply instantiating a few extra instances of their applications. One question I do have is do all the cloud providers follow Amazon like policies? The authors used networking tools and mentioned that other tools could also be used for aiding the attacks. What could be some of the other tools?

This paper discussed several security issues for applications running in the cloud, where multiple instances owned by different groups might be located on the same physical machine. In particular, they discussed ways to attain co-residence and possible types of side-channel attacks. They implemented their attacks on Amazon's EC2 service, which places each instance in a virtual machine.

The problem the paper addresses is that application writers may want to use the cloud, but if they have sensitive data, they do not want anyone else to be able to see it. The paper assumes that these users do trust the cloud provider; it is only other malicious users they are worried about. The common assumption is that even if side-channel attacks between two virtual machines on the same physical machine are possible, it is unlikely that the malicious user would be able to arrange things so it is on the same machine as the target, or even tell when it is.

The paper contributes a method for achieving co-residence with a target. To do this, the authors mapped out the cloud in terms of where specific types of instances (zones and service requirements) were placed, and found that instances of the same type were placed on the same set of physical machines, especially when launched close in time to the victim instance. They could also tell when they were co-resident with the victim by looking at the number of network hops between them; even besides that, if the load of the victim could be controlled (for example by requesting many pages from a server), it was possible to use the cache latency to determine co-residency. With this information, it was possible to launch instances such that they often achieved co-residency with the target. Once the attacker has an instance known to be on the same physical machine as the victim, the attacker can try side-channel attacks. For example, by looking at the cache latency, it might be possible to determine what the load of a victim is (if it is a webserver), or to do a keystroke timing attack.

The paper does not provide much in the way of defences against the type of attacks it discusses. It makes the point that even if you try to blind the side-channels or make determining co-residency more difficult, it is hard to be certain that a dedicated attacker could not find a way. It advocates instead telling the users about these risks, so that they could choose to use only physical machines guaranteed to have no other instances present (similar to the large and xlarge instances for amazon). Although this might mitigate some of the security problems, it also would defeat some of the point of using the cloud to start with (such as high utilization of physical machines). On the other hand, maybe if you really care about the security of some of your information, a public cloud is not an ideal place to store it in the first place.

Summary:
Recently, there have been many changes in the computer industry which leverage vitalization to offer greater efficiency and flexibility. These cloud computing techniques all seek to share physical resources among many users to make average load more predictable, reducing the need for over provisioning. This type of inter-party load balancing encourages fine grained sharing of resources to reduce the worst case behavior of any one instance. These same goals also encourage entrusting parties to share physical resources, and this sharing does not come without a cost to security. Shared resources subject to contention also function as a shared communication media between resource users. In this paper, the authors explore the security implications of this type of sharing.

Contributions:
The security community has researched side-channel information leakage attacks for many years. Even so, new side-channels are continually created as new hardware and software techniques emerge. This paper builds a accurate, predictive model of Amazon EC2 without inside information about the service. This model enables the authors to design and carry out co-tenancy attacks (obtaining an EC2 instance sharing resources [disk, CPU, memory, cache, etc.] with a VM belonging to a target organization).

The mapping and monitoring techniques presented in this paper exploit design choices fundamental to the success of Cloud Computing services. Because of the nature of the the features exploited, some of these attacks are difficult or impossible to block without giving up the load balancing and resource sharing that make services like EC2 so efficient and flexible. For instance, a user hoping to tolerate high peak loads would prefer many small instances with none sharing resources as opposed to a few dedicated machines. The argument that a user can always dedicate a host is valid, but this removes most of the benefits supplied by cloud computing.

As side channel attacks themselves are well studied, the authors dedicate most of their time to the problem of co-tenancy. They do note that fine grained side-channel attacks are unlikely to work well in a noisy environment like EC2, but they also demonstrate that keystroke timing attacks are feasible.

Questions/Comments:
Considering that nearly all EC2 instances will be automatically managed, it seems that keystroke timing attacks would be useless on any deployed/stable service. On the other hand, other coarse grained side-channels exist. Even information about a competitor's load/instance type/instance count can be highly valuable.

Problem addressed:
=============
This paper demonstrates security risk that arise through the use of shared physical resources maintained by a third part vendor (like in cloud) among distrustful users. They show that it is possible with not-so-small confidence, to learn and exploit many internal policies and structures of such shared infrastructure to mount various side channel attack on other user's programs. They also discuss possible approaches to enhance security in such environments.

Summary:
=======
The paper primarily talks about two tasks to complete the attack on the victim process. First is the placement, where the adversary tries to place its malicious process along with the victim's process on the same physical CPU where many resources like cache etc, are shared. Second, once adversary achieves co-placement, it can learn/extract information about the victim's process by using different techniques of side-channel attack. To achieve the first task, authors showed that its possible to approximately map the internal structure of the cloud using network probing. For Amazon's EC2 cloud infrastructure, the authors empirically found out that there is correlation between the instance type and availability zone with the static ip addresses of the machine where a process is run. This can help the adversary to enhance probability of co-residing with the victim, once the victim's instance type and availability zone is figured out. The authors then also experimentally established that, through IP address and network probing co-residence of adversary and victim process can also be determined. Another observed internal cloud infrastructure policy that was exploited was the fact that process spawned close in time tend to be resident on machines whose IP addresses are close. This can also be exploited by the adversary by tracking when the victim's process is getting scheduled to run. Once adversary can place its malicious process in the same physical machine as that of the victim's process, known methods of side-channel attacks can exploit this. One of the most popular way is to exploit shared cache architecture to observe cache behavior and extract sensitive information about the victim's process. Authors later demonstrated that even if network probing advantages are screened out, load-based co-residence detection can also be used in the attack. For solution, the authors proposed two possible approaches. First, is to obfuscates internal structure of the services and placement policy to make it harder for the adversary to co-place a malicious process with victim's process on same machine. Secondly, the architecture itself can be made more robust against any kind of side-channel-attacks.

Relevance/Importance:
================
I think this work has great impact on the way security risks are apprehended in cloud computing setup. The paper shows that even among thousands of machines in a cloud, it is possible to co-reside with a target process in the same machine with not-so-small confidence. Even with the virtualization that the cloud services generally offer, they are still vulnerable to side-channel attacks. This paper also insinuates towards another possible business model emerging out of this, where users may want to pay a bit extra price to make sure that processes of no other account holder is run on the same machine, when their job are running on them, if preventing any kind of side-channel attacks is of paramount importance.

Summary:
Cloud computing environment may introduce new security vulnerabilities. This paper argues that cotenancy (multiple different users on the same physical infrastructure) enables cross-vm leakage. The authors discuss the mechanisms for achieving and determining co-residence by manipulating placement strategies directly or indirectly exposed by the cloud provider. While in theory arguments presented in this paper may be true, in practice I expect that is extremely hard to accomplish an attack on a particular user of the cloud. Even if security was a real tangible problem, the authors admit that simply reserving the workstation for a single user is sufficient to avoid these problems. Therefore, any user concerned with malicious attacks can simply pay a premium to avoid cotenancy with potential attackers.

Problem:
The problem is that by using cloud service, users loose control over scheduling. The cloud provider schedules users jobs with the cloud's needs in mind, such as load balancing. Unfortunately, as the authors of this paper have discovered, the current cloud IP assignment enables cloud cartography as well as co-residence checking. Simple obfuscation techniques can prevent at least network-based co-residence checks. Similarly, cloud cartography can be prevented by using more robust IP assignment techniques. Even so, the authors argue that the attacker can use other properties of the cloud to achieve co-scheduling and check co-residence. The problem this paper attacks is exposing and measuring the potential thread.

Contributions:
The contributions of this paper are quite numerous. Among these are 1) Revealing cloud vulnerabilities, such as potential for cloud cartography, 2) discussing techniquest for determining co-residence based on network parameters, 3) techniques for achieving co-residence by exploiting cloud's placement techniques and abusing placement locality, 4) finally, discussing the potential for cross-vm information leakage.

Comments:

I am extremely skeptical about the problem described in this paper. Specifically, a large part of this paper assumes that the attacker 1) knows the target, 2) knows that the target is using the same cloud services, 3) knows what kind of placement requirements the target has, 4) knows when the target service is launched. The last assumption in particular bothers me. The authors claim that by abusing placement locality, the attacker can achieve co-scheduling. Presumably, the attacker can monitor server's state and then launch an attack when the instance reappears. This assumes the attacker knows exactly where the server is and is able to monitor it. Not only that, it assumes that the server will in fact disappear and reappear again.

I think that this paper makes a lot of assumptions and presents very weak arguments for what exactly can happen when the attacker indeed gets co-scheduled with the victim. In my opinion this paper would be much stronger with a realistic evaluation of successful attack probabilities.

**HEY YOU GET OFF THE CLOUD**
=============================

- Summary

This paper explored *new* security threads (i.e side channel attack) in cloud computing environment due to *multi-tenancy* nature of the cloud. Using a step by step strategy (from cartography the cloud to placement and extraction), the authors showed how practical and possible those kinds of attack can occurs in cloud infrastructure. Some hints are suggested to inhibit discussed security holes.

- Problem

Cloud is cool (economy of scales, low capital expenditure, etc...) but exposed to new security risk. The multi-tenancy nature of the cloud (i.e VMs from different customers can be on the same physical machine) creates new threat - the attacker can break the isolation between VMs and violate confidentiality. The problem is: how practical this kind of attack can occur? what is the chance for attacker/victim being on the same physical machine? how to detect co-residency? how to exploit co-residency for malicious purpose? ... This paper addresses some of these question.

- Contribution

The main contribution of this paper is the demonstration of the new security threat leveraging the fact that in cloud, VMs can share physical machine. The authors show how attacker can learn the VM placement policy in the cloud, cartography the cloud, obtaining reasonable co-resident probability, and attack the victim.
- To learn about cloud mapping, network probing techniques are used. Data collecting from network probing is analyzed to obtain some hints about the cloud map.
- To check if 2 instances are co-resident, the authors compares their Dom0 IP address to see if they match, observe the packet round-trip times between the two and see it it is small. The authors also check if they have close internal IP address.
- Using above techniques, to obtain co-residency, the attacker can use brute force (i.e launching as many VM instances as possible) or leverage the cloud VM placement policy (i.e if an attacker can launch his VMs instance right after target VM instance is launched, it is more likely that the cloud can place two instances in the same physical machine).
- Once co-residency is obtained, attacker can use a variety of side-channel attack techniques to learn about the victim.
After all, the authors suggest several lessons for cloud provider in dealing with above mention security risk, among those lesson, exposing the risk and placement policy directly to users are consider the best (by the author)

- Flaw/Comment/Question

I am not a security guy, but i think this paper is cool, and interesting to read. There is one point in this paper that make me confused. The authors claim that if an attacker can launch his VM instances right after a target victim instance is launched, the co-resident chance can be 40%. But *HOW* do we know when the target victim is launched. Cloud environment is very dynamic. One can hide and instance for an hour, running some task, and stop. Therefore, in my opinion, it is very difficult to detect that moment.