Forgot your password?
typodupeerror
Encryption Cloud Security The Internet Virtualization Technology

Attack Steals Crypto Key From Co-Located Virtual Machines 73

Posted by Unknown Lamer
from the can't-patch-that dept.
Gunkerty Jeb writes "Side-channel attacks against cryptography keys have, until now, been limited to physical machines. Researchers have long made accurate determinations about crypto keys by studying anything from variations in power consumption to measuring how long it takes for a computation to complete. A team of researchers from the University of North Carolina, University of Wisconsin, and RSA Security has ramped up the stakes, having proved in controlled conditions (PDF) that it's possible to steal a crypto key from a virtual machine. The implications for sensitive transactions carried out on public cloud infrastructures could be severe should an attacker land his malicious virtual machine on the same physical host as the victim. Research has already been conducted on how to map a cloud infrastructure and identify where a target virtual machine is likely to be."
This discussion has been archived. No new comments can be posted.

Attack Steals Crypto Key From Co-Located Virtual Machines

Comments Filter:
  • by ChristW (18232) on Tuesday November 06, 2012 @06:31AM (#41891701) Homepage

    The published paper is an interesting read. Obtaining the crypto key to libgcrypt is only one application. In general, the authors say, it is possible to construct a side-channel attack on other, unrelated, processes in the attacked VM.

    • by Anonymous Coward

      since you read it, what does this mean? that you can see into another vm from a different one? or from the hyperviser? (which should be obvious)

      • by cbhacking (979169)

        "See" from one VM into another, on the same physical hardware. It's a cache-based attack; the attacker fills the cache lines of the CPU, then yields and hopes the hypervisor schedules the other VM on the same CPU core next, and that the other VM is executing a particular set of cryptographic operations. These operations have a very specific behavior with regard to the processor cache. When the attacker's process runs again, it determines which of its cache lines were flushed, and this information tells it s

        • by mysidia (191772)

          See, all the VM needs to do to avoid this attack, is to alter the set of cryptographic operations executed on the CPU, so that no matter what value is in each bit key position, the same cache lines will get dirtied.

          If a Key bit being '1' has a different computation than a key bit being '0', then perform both computations, and discard the result of the unneeded one.

  • by Anonymous Coward on Tuesday November 06, 2012 @06:32AM (#41891703)

    "public cloud infrastructure". The very thought of that makes me cringe, then laugh at the absurdity of it.

    We can't even code bug free operating systems. What makes anyone think we can code a bug free hypervisor? I'm still confused as to why people believe that VMs are inherently secure- are they secure because VMware/Xen/Oracle says they are? Or are they secure because they've been tried and tested in the fires of time? All I ever see about hypervisors these days is some inflated marketing terms or new "cloud" interoperability features or some other random junk that solves an imaginary problem someone first had to go out of their way to create. I've never seen anyone actually come out and say "This version of our hypervisor is even more secure then the last because of XYZ!".

    The company I work for makes extensive use of "cloud influenced" features in-house. It's awesome to be able to two-click a LAMP stack into existence through a nice web portal or do the same for a couple of Win2K8 instances. Some idiot was preaching about outsourcing our hardware to someone else and putting everything "in the cloud". Luckily management saw it for the farce it was and put that guy in his place pretty quickly.

    So again, I'm really curious as to why people explicitly trust: A) Their services/platforms to someone other then themselves, and B) expect that VM hypervisors are bullet proof.

    • by DarkOx (621550) on Tuesday November 06, 2012 @06:45AM (#41891759) Journal

      Well a hypervisior is in theory a simpler beast than a operating system. Depending on your prespective it has less attack surface. I think thoes are good reasons to think we could get it right. The real source of trouble is the x86 world just does not provide the hardware isolation features needed.

      • by Anonymous Coward

        The real source of trouble is the x86 world just does not provide the hardware isolation features needed.

        Not true. Highly secure operating systems have been built on the x86 architecture. For example, see the GEMSOS (Gemini Secure Operating System), evaluated at the highest DoD security level (A1, in the old Trusted Computer Evaluation Criteria) and still a commercial product.

        The problem is not the hardware isolation features, it's that OS developers don't take advantage of them. And, even more importantly, they don't follow secure development practices. Hypervisors are smaller than general purpose operating s

    • by photon317 (208409) on Tuesday November 06, 2012 @06:46AM (#41891765)

      I don't think reasonable people expect hypervisors to be bulletproof. Security is a sliding scale though, and for many purposes the security level offered by a responsible cloud provider is good enough for what they're hosting there. If my bank hosted their critical system in AWS, I'd freak out. If Pandora hosts systems there to stream music to me? I could care less. If Pandora puts their billing system there that has my credit card number? Ok, I start to care a little more, but the risk is manageable if they're being careful about the design, and ultimately if someone rips their whole CC database, my CC company or I will notice the fraud activity quickly and issue me a new card. Life goes on.

      Why do companies want to use virtualized infrastructure in the first place? Because it offloads work that's not directly relevant to their business. Let me quote directly from Bruce Perens' recent Ask Slashdot responses:

      There is no point in having your own programmers write anything that is not a customer-visible business differentiator for your company if you can get it from the Open Source community. A “business differentiator” in this case means something that makes your company look better than a competitor, to the customer directly. Too much “glue code”, and “infrastructure” is written by organizations that have no real need to do so if they would adopt Open Source. The message that is driving them to do so is the huge stack of cash being made by the companies that do use us.

      He was talking about it making sense for companies to build on top of OSS lower-layers. The same applies to the cloud infrastructure stuff. For most businesses, infrastructure is not a differentiator anymore. Why have company employees concerned with managing network switches, racks, cooling systems, datacenter fire protection codes and systems, insurance, servers? Or calling vendors and leading them in the building to replace failed drives and RAM modules, or even giving a crap about hardware at all?

      If my company's purpose in life is to deliver, e.g., some social iPhone app and a backend network service that supports it, I have no differentiating interest in that level of infrastructure. I still need an IT department, but it can be a small one focused on using that cloud infrastructure correctly (e.g. security, configuration management, etc). When you can shift off that whole layer of complexity to a large-scale specialist, you've reduced the total complexity your company has to manage directly. Focus on the areas that matter, not the common ground. Did your company design, engineer, and build its own kitchen appliances for the company breakroom? Didn't think so...

      • by mpeskett (1221084) on Tuesday November 06, 2012 @09:36AM (#41892581)

        When you can shift off that whole layer of complexity to a large-scale specialist, you've reduced the total complexity your company has to manage directly. Focus on the areas that matter, not the common ground. Did your company design, engineer, and build its own kitchen appliances for the company breakroom? Didn't think so...

        Surely in handing over responsibility for managing that complexity, you also hand over control of what could be intensely critical components of your business. They may do a perfectly good job at a lower cost, but in the (hopefully infrequent) event that the shit hits the fan, the job of fixing it is out of your hands and out of your control and that ought to be scary.

        I don't know. Maybe it makes enough sense in the bulk of cases to be a good plan, but the risk of having your entire infrastructure yanked out from under you because of a black swan event or just a regular-grade fuck-up at an unrelated company sounds like something best avoided.

      • by sapgau (413511)

        Perfectly said but, when you are giving away the keys you are trusting your cloud provider 100%.

        When your boss asks you, are we 100% sure that we can trust the cloud what would you say?

        The government/hacker group can come to your cloud provider and shut you down base on something done without warning. Usually done by one of your employees, or the cloud provider employees. Probably they were hosting something illegal/controversial in your cloud space without you knowing. How do you recover? How do you setup

    • by mrbluze (1034940)
      Better still, don't trust hardware any more than you trust software. A virtual environment has the potential to bring the worst of both. I am against flying in clouds, lest they be connected to cumulo granite. I am all in favor of research that reveals how centralization of information is bad for the vast majority, and this goes to demonstrate the problem quite well.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      I'm still confused as to why people believe that VMs are inherently secure

      You're missing the point. No system is secure. What's nice about VMs is ... as many as you need, same price. So just chuck them often, don't even worry about checking them to see if they've been compromised. How awesome would it be if we could just destroy and replace physical desktops and servers 100 times a day? That would get expensive... but not with VMs, which allows you to move the security layer back to the image, and screw securing the actual running system.

      • by Anonymous Coward

        I'm still confused as to why people believe that VMs are inherently secure

        You're missing the point. No system is secure. What's nice about VMs is ... as many as you need, same price. So just chuck them often, don't even worry about checking them to see if they've been compromised. How awesome would it be if we could just destroy and replace physical desktops and servers 100 times a day? That would get expensive... but not with VMs, which allows you to move the security layer back to the image, and screw securing the actual running system.

        Nice. So it sets a time limit on attacks... to be successful, they'd have to infiltrate before the VMs scheduled destruction and replacement... and all VMs, compromised or not, have a clocked lifetime. Whatever the attacker is trying to do, they must do it fast, because the destruction of their target forces them to begin again.

      • I'm still confused as to why people believe that VMs are inherently secure

        You're missing the point. No system is secure. What's nice about VMs is ... as many as you need, same price. So just chuck them often, don't even worry about checking them to see if they've been compromised. How awesome would it be if we could just destroy and replace physical desktops and servers 100 times a day? That would get expensive... but not with VMs, which allows you to move the security layer back to the image, and screw securing the actual running system.

        Yes... That way they can re-build the vulnerable system. I hear it takes a long time to steal credit card information...

        • Re: (Score:2, Informative)

          by Anonymous Coward

          I'm still confused as to why people believe that VMs are inherently secure

          You're missing the point. No system is secure. What's nice about VMs is ... as many as you need, same price. So just chuck them often, don't even worry about checking them to see if they've been compromised. How awesome would it be if we could just destroy and replace physical desktops and servers 100 times a day? That would get expensive... but not with VMs, which allows you to move the security layer back to the image, and screw securing the actual running system.

          Yes... That way they can re-build the vulnerable system. I hear it takes a long time to steal credit card information...

          You're not seeing it. The system isn't vulnerable until the attack gains control of image construction. The time between VM destruction and replacement can be quite small... every minute if you wish, the hardware and software can handle this with no interruption of service. Let's see an attacker infiltrate a VM, and then successfully perform a side attack on another VM, and get what they're after, in under a minute. Likely, however, security checking is what occurs every minute or less (hash comparisons or

      • On the other hand, if an attacker managed to convince the hypervisor to include a malicious virtual machine onto the system, then your security software only has a minute to try and detect it before a new copy is instantiated. Meanwhile it could have full access to the SAN and the internet.
    • by Anonymous Coward on Tuesday November 06, 2012 @08:35AM (#41892179)

      I think the details of what's actually been done are relevant here.

      This is a side-channel attack against a specific piece of code which has a very clear operational signature.

      It's a brute-force implementation of exponentiation mod p using repeated squaring, such that bits from the key directly result in jump operations, and one side of the jump is very cheap and one side is very expensive. Modern implementations of the same exponentiation process (e.g. in OpenSSL) have optimizations which prevent this from being the case.

      It is amazing that it's been done at all, but the number of assumptions it rests on regarding precisely what the other VM is running do seem to make it an attack of little practical value. This is more a piece of interesting math than it is an indictment of cross-VM security. And the appropriate response is probably some more neat math to make an algorithm for the same problem which is provably not attackable via this methodology.

      • by TubeSteak (669689)

        And the appropriate response is probably some more neat math to make an algorithm for the same problem which is provably not attackable via this methodology.

        The reason this attack works is because they can force a known memory state and then watch for changes.
        Changing your encryption isn't going to fix it. Mucking up the L1 Cache will.
        There might be a small performance penalty involved with screwing around with the L1, but that's better than the alternative.

        I'm also amused that "A team of researchers from the University of North Carolina, University of Wisconsin, and RSA Security"
        think "âoeAt present, this is a fairly elaborate attack and we would expect i

    • by indeterminator (1829904) on Tuesday November 06, 2012 @08:59AM (#41892291)

      I'm really curious as to why people explicitly trust: A) Their services/platforms to someone other then themselves

      The hosting providers have a financial interest in being trustworthy. If they lose the trust, they lose their business. Doing it yourself has its own failure modes too.

      Also, for many new companies running their own datacenter would be cost-prohibitive, so trusting may be the only choice they have.

      • by sl4shd0rk (755837)

        The hosting providers have a financial interest in being trustworthy.

        Oh, you must be referring to EBS*. There are only two reasons why "Teh Cloudz" are so popular right now. It's sexy to do (like outsourcing was 10 years ago), and PHB doesn't have to staff an Admin to keep a Hypervisor up. In a few years, the cost of Cloud computing along with massive outages when things do go wrong, are going to be prohibitive to it's longevity. It's a fad. Being sold on the assumption of 100% uptime. First time PHB gets a scathing call from the CEO because EBS coughed a hairball, he will

        • Oh, you must be referring to EBS*.

          I'm aware, thanks. I don't have any stuff running on AWS in the US, but I lost some volumes the last time they had an EBS meltdown at eu-west-1. That was expected, they even give an expected yearly failure rate for those. Good thing I was taking snapshots as recommended.

          (I was much more concerned about the fact that the same incident revealed a data loss bug in their snapshot code. Good thing I also back up outside their infrastructure.)

          It's a fad. Being sold on the assumption of 100% uptime.

          Computing is a fad. Being sold on the assumption of increased efficienc

    • I can see the benefit of cloud services for non-critical applications without strict security requirements. If business doesn't stop if it goes down and getting hacked has trivial consequences, I think it's ok to dump it in the cloud.
  • Detailed blog post (Score:2, Interesting)

    by Anonymous Coward

    You can find a more detailed blog post about this here:

    http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html

  • by dachshund (300733) on Tuesday November 06, 2012 @07:27AM (#41891915)

    This post gives a high-level summary of the attack:

    http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html [cryptograp...eering.com]

    (I previously posted this as AC, but it vanished.)

  • if the attacker has sufficient access to the host to study the vm's execution profile then i suspect the attacker can do a lot more than capture that key.. in the uses I would expect people to care about, web services running on a vm on the net, this implies that the attacker already has ssh access to the host machine. so an assumption of this vulnerability is that the host system is completely compromised. in such a case the attacker will have other options to get that key. as a side note, i dont know
  • just bind the cryptographically sensitive process to a dedicated processor.
    • by cbhacking (979169)

      Well, and exclude that processor from ever executing code for other VMs. Remember that a process is an OS-level concept. The OS can certainly set affinity to a single CPU and exclude all other processes from using that CPU, but that only works for intra-OS context switches. When the hypervisor context-switches the execution to a different VM, you get a different OS (that of the attacker) executing on (potentially) the same processor. The attacker's OS has no ability to see, much less reason to respect, the

  • by Traiano (1044954) on Tuesday November 06, 2012 @08:59AM (#41892299)
    Before anyone gets carried away, here are a few important quotes from TFA:
    • "We assume the attacker knows the software running on the victim VM and has access to a copy of it"
    • "We demonstrate how to use interprocess interrupts (IPIs) to abuse the Xen credit scheduler in order to arrange for frequent interruptions of the victim’s execution by a spy process running from within the attacker’s VM...[then much later]...we leverage the tendency of the Xen credit scheduler to give the highest run priority to a VCPU that receives an interrupt."
    • "We will only be able to spy on the victim when assigned to the same PCPU, which may coincide with only some fraction of the victim’s execution."

    In other words, this exploit requires: knowing what cryptographic software is being run, the presence of Xen and an apparent security hole therein, and lucky core colocation of the VMs in an environment that could easily have dozens of VMs running against more than a dozen cores "over the course of a few hours".

    In short, all of this is unlikely to be reproducible outside of a lab.

    • It also appears that it doesn't work if there are more than two virtual machines running on the same physical CPU, or if the attacking VM is the only one running on a given CPU.

      With 3 or more VMs on the same CPU, the cache gets populated by virtual machines other than the targeted "victim" machine, so the attacker doesn't know which is affecting what. And if the attacking VM is alone on the CPU, it can't find any other VMs to attack.

    • The StuxNet attack vector was probably thought of in the same way - until it was used. When there is a high value target, getting all the ducks in a row is not impossible, it's the reason professionals are called in. You only have to make it work once (though you have to avoid getting caught on all the other attempts).

    • by Hatta (162192)

      this exploit requires: knowing what cryptographic software is being run, the presence of Xen and an apparent security hole therein, and lucky core colocation of the VMs in an environment that could easily have dozens of VMs running against more than a dozen cores "over the course of a few hours".

      It doesn't seem that far fetched to me. Call up the cloud provider as a customer and ask what technology they use. If they say Xen, go ahead, if not find another cloud provider.

      Then you guess what cryptography sof

There is no distinction between any AI program and some existent game.

Working...