Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Attack Steals Crypto Key From Co-Located Virtual Machines

Unknown Lamer posted about 2 years ago | from the can't-patch-that dept.

Encryption 73

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."

Sorry! There are no comments related to the filter you selected.

Someone else's hardware is not secure? (-1)

Anonymous Coward | about 2 years ago | (#41891689)

Who knew!

Not just 'a' crypto key (4, Informative)

ChristW (18232) | about 2 years ago | (#41891701)

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.

Re:Not just 'a' crypto key (1)

Anonymous Coward | about 2 years ago | (#41891879)

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)

Re:Not just 'a' crypto key (2)

cbhacking (979169) | about 2 years ago | (#41901495)

"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 something about the operations the other VM is doing.

Obviously, this is a very slow and error-prone operation, not something you can do in real-time, or even within a few seconds (which, on modern CPUs, means a few billion cycles). Rather, the attack requires hours - tens of trillions of CPU clock cycles - to get enough samples of the CPU behavior to determine which samples are meaningless, and to have enough information to piece together the cryptographic key. Obviously, this assumes that the other VM on the same host is frequently engaging in cryptographic operations using this key.

I don't think I'd go so far as to call this attack truly practical, yet, but it's possible in at least some situations. That fact, by itself, is quite scary for two reasons. First, stealing a key is the kind of thing that you don't need to do Right Now in most cases; if you can do it within a reasonable time frame (which may be months), that's enough. Second, these types of attack are almost always slow and/or difficult when first demonstrated. The problem is, now that the attack is known to be possible, it has garnered a lot of attention and many people will be examining it to see if they can improve on it somehow.

Re:Not just 'a' crypto key (1)

mysidia (191772) | about 2 years ago | (#41902787)

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.

Don't trust hardware you don't own. (5, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Don't trust hardware you don't own. (4, Insightful)

DarkOx (621550) | about 2 years ago | (#41891759)

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.

Re:Don't trust hardware you don't own. (1)

Anonymous Coward | about 2 years ago | (#41895657)

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 systems, so it should be easier to make them secure (minimization is one of the secure development techniques), but there's no evidence that the Hypervisor developers are being very strict with regard to building security into their products.

http://books.google.com/books?id=P4PYPSv8nBMC&pg=PA86&lpg=PA86&dq=gemsos&source=bl&ots=dO80PeE8tN&sig=AFU-QoM0twmv-hEXi08xWbq442w&hl=en&sa=X&ei=EUmZUOG0F8jnrAHi9ICoDw&ved=0CFMQ6AEwBg#v=onepage&q=gemsos&f=false

Re:Don't trust hardware you don't own. (5, Interesting)

photon317 (208409) | about 2 years ago | (#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...

Re:Don't trust hardware you don't own. (-1, Troll)

L4t3r4lu5 (1216702) | about 2 years ago | (#41892167)

If Pandora hosts systems there to stream music to me? I could care less.

How much less could you care? Please; I'm interested.

This is at best a tautology, at worst nonsense. "I could care less" tells us nothing about how much you care; You could be overjoyed at the news, in which case in being only slightly less excited you would be "caring less". "I couldn't care less" is unequivocally an expression of your lack of enthusiasm or interest in the subject, and in that sense informative.

Some will call me a pedant, but that's fine; Attacking me as a person doesn't detract from my argument.

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41892229)

> Some will call me a pedant, but that's fine; Attacking me as a person doesn't detract from my argument.

But what if I call your argument pedantic?

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41892237)

Now you're just being pedantic. I couldn't care less ;)

Re:Don't trust hardware you don't own. (1)

L4t3r4lu5 (1216702) | about 2 years ago | (#41892497)

Then you draw an irrelevant conclusion, at your own expense.

Re:Don't trust hardware you don't own. (1)

YodasEvilTwin (2014446) | about 2 years ago | (#41900207)

"I could care less" is an idiom that means "I couldn't care less". Yes, it's an abuse of language, but it's too damn late and one of thousands of such abuses. And, if you haven't noticed, the English language doesn't have a particularly consistent set of rules anyway. You prescriptive moron.

Re:Don't trust hardware you don't own. (3, Insightful)

mpeskett (1221084) | about 2 years ago | (#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.

Re:Don't trust hardware you don't own. (1)

sapgau (413511) | about 2 years ago | (#41895763)

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 gigabytes of data and code on another server in a short time?

Re:Don't trust hardware you don't own. (2)

mrbluze (1034940) | about 2 years ago | (#41891853)

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:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41891913)

I am against flying in clouds, lest they be connected to cumulo granite

Apologies for my bad taste, but flying into cumulo granite is akin to flying into cumulo rebar, and has been purposefully performed only once before. It lead to global condemnation.

Re:Don't trust hardware you don't own. (3, Insightful)

Anonymous Coward | about 2 years ago | (#41892025)

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.

Re:Don't trust hardware you don't own. (1)

Anonymous Coward | about 2 years ago | (#41892047)

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.

Re:Don't trust hardware you don't own. (2)

bob')DROP TABLE user (2535244) | about 2 years ago | (#41892169)

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:Don't trust hardware you don't own. (2, Informative)

Anonymous Coward | about 2 years ago | (#41892245)

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 whathave you), and the VM purging happens using a slightly longer period, say every 5 or 10 or 15 minutes. In this scenario an attacker must accomplish their goals nearly instantaneously to be successful, which means they have no time to "hack" away at a system before it no longer exists. This is not a bad idea considering the alternative, which is to thicken security and put more locks on the doors. It doesn't matter if you have a vault for a front door, it's only a matter of time before a determined theif gets in your house, and you can stand there with a shotgun, but you can't shoot all the thieves. But if you blow up your house, there is nothing there to steal, nothing to break into...

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41893449)

But if you blow up your house, there is nothing there to steal

Except for information, right? But who would want to steal information.

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41893955)

It generally takes longer than a minute to start a database, unless you will have some way to keep the "instance" connections live between all those starts and stop, in which case the attacker will attack that point of weakness.

And, as for one minute, I have had systems (remote) that had problems where they were rebooting every 2-3 minutes, I would log in, look around, update my script, then after reboot, run that script, see if the problem was fixed, if not, rinse, lather, repeat until the system problem was fixed. If I can do this I can bet there are hackers that can do similar stuff in under 1 minute. Yes, the target becomes a "bit" harder, but then again, I think the "security through obscurity" would leave those systems more likely to be easily compromised. And good luck with forensics unless you plan to keep copies of all those VMs around (ouch).

I could also see patch management and testing take a back seat to all the necessary rebooting and thus leave volunerabilities open for longer than they would in a normal environment.

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41900631)

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 whathave you), and the VM purging happens using a slightly longer period, say every 5 or 10 or 15 minutes. In this scenario an attacker must accomplish their goals nearly instantaneously to be successful, which means they have no time to "hack" away at a system before it no longer exists. This is not a bad idea considering the alternative, which is to thicken security and put more locks on the doors. It doesn't matter if you have a vault for a front door, it's only a matter of time before a determined theif gets in your house, and you can stand there with a shotgun, but you can't shoot all the thieves. But if you blow up your house, there is nothing there to steal, nothing to break into...

Wrong, as always when someone is too much of an enthusiast.

These often-replaced VMs won't protect you. If I learn how to break in, I notice the "machine timeout" soon enough. But I know about this little trick. And know I know how to break into your short-lived machines, so all I need is a "session manager" that re-establish my precence a few seconds after you instantiated your new machine.

Further, you can't do everything from one-minute machines. There has to be persistent storage somewhere, so that the contents of your webshop (or bank balance, stock portfolio, or whatever) isn't reset every minute. The short-lived machines must have write access there. As an attacker, I will abuse that and store my virus/botnet sw in your persistent storage.

And you have a harder time catching me. I needed some time for perfecting my attack. In that time, I left lots of traces. I made a mess. But the machines containing that evidence got deleted long ago. Now my attack is perfect, removing all logs as soon as I get in. You can save a snapshot now, and it won't tell you anything.

Re:Don't trust hardware you don't own. (1)

camperdave (969942) | about 2 years ago | (#41892905)

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.

Re:Don't trust hardware you don't own. (5, Informative)

Anonymous Coward | about 2 years ago | (#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.

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41895727)

The point is that information is leaked through a previously unsuspected channel between what were assumed to be completely separate VMs. How many other, still unknown channels are there? There's no way to enumerate them. That's the problem with low-assurance operating systems. Just because a hypervisor is less complicated than an general-purpose OS is no guarantee that it was built to be secure.

Re:Don't trust hardware you don't own. (1)

cbhacking (979169) | about 2 years ago | (#41901559)

Actually, cache attacks have existed, and been well-known in the cryptographic community, for a *long* time. The only thing that sets this attack apart from the others in history is the fact that the attack was carried out across two VMs (different logical machines, same physical one), rather than across two processes on the same (logical) machine. That's a significant finding, to be sure, but it's not even a new idea to try it; the novelty is that the researchers succeeded.

Re:Don't trust hardware you don't own. (1)

TubeSteak (669689) | about 2 years ago | (#41896875)

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 it to be mounted only by a sophisticated attack organization such as a nation-state,â
This team is not a nation-state, but they think only nation-states can implement such attacks?
o.O

Re:Don't trust hardware you don't own. (3, Interesting)

indeterminator (1829904) | about 2 years ago | (#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.

Re:Don't trust hardware you don't own. (1)

sl4shd0rk (755837) | about 2 years ago | (#41893327)

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 look at other options.

* http://tech.slashdot.org/story/12/10/22/1941237/amazon-ebs-failure-brings-down-reddit-imgur-others [slashdot.org]

Re:Don't trust hardware you don't own. (1)

indeterminator (1829904) | about 2 years ago | (#41901175)

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 efficiency and cost savings. In a few years, we'll be back to mechanical typewriters due to prohibitive cost of computing.

I know my cloud provider doesn't promise 100% uptime or durability for any single thing I run in there. I take it into account and plan around it.

I have also seen downtime and data loss in places where everything was done in-house, before "Teh Cloudz" were popular. Somehow not being in the cloud did not magically protect from that.

Re:Don't trust hardware you don't own. (1)

HaZardman27 (1521119) | about 2 years ago | (#41896817)

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.

Re:Don't trust hardware you don't own. (0)

Anonymous Coward | about 2 years ago | (#41904713)

>>>>> an imaginary problem someone first had to go out of their way to create

I like this. One may disagree with Larry Ellison any many things but he was right when he got mad about all the hype about VM/Cloud, but he caved in in the end.

Who would have thought...... (-1, Troll)

banbeans (122547) | about 2 years ago | (#41891705)

That programs running on the same hardware could see what another program was doing.
This one is a great big DUH!

Re:Who would have thought...... (4, Insightful)

Anonymous Coward | about 2 years ago | (#41891955)

No, it isn't since modern operating systems tend to isolate programs from each other, and in the case of this article the programs are even running in disparate virtual machines, which should put a wall between the two. It is only through exploiting the processor cache that the key could be extracted. The attacker monitors how the victim fills the instruction cache. Since the victim's crypto algorithm follows different code paths depending on the key, the researchers were able to determine key.
This kind of side-channel attack was not universally thought practical so this is news and would be good to think about how to mitigate this problem.

Re:Who would have thought...... (1)

VortexCortex (1117377) | about 2 years ago | (#41893167)

would be good to think about how to mitigate this problem.

Simple: Use a different core / cache for different VM instances... Oh, wait.

change the algorithm (2)

Chirs (87576) | about 2 years ago | (#41893961)

If necessary you could simply do unnecessary work on one of the code paths so that they end up doing the same amount of work on each path.

Re:change the algorithm (0)

Anonymous Coward | about 2 years ago | (#41896483)

If necessary you could simply do unnecessary work

But, if it's necessary, than it can't be unnecessary work, but the instruction was for unnecessary work... HERMAN COORDINATE.

In controlled conditions (0)

Anonymous Coward | about 2 years ago | (#41891721)

All timing attacks are done in controlled conditions. This is extremely important. Most of them don't work well, if it all, in busy environments.

Re:In controlled conditions (1)

Anonymous Coward | about 2 years ago | (#41891781)

All timing attacks are done in controlled conditions. This is extremely important. Most of them don't work well, if it all, in busy environments.

And what do you know about who's controlling the conditions when you host your data in "the cloud"?

TOO MANY IFS ANDS BUTTS !! (0)

Anonymous Coward | about 2 years ago | (#41891811)

Bring a rubber hose !! Start with a "this is going up your nose unless" !! You can imagine the other places !! Leaves no marks !! Works every single time !! No IFS ANDS BUTTS !! Stupid, stupid boffins !! Always doing things the hard way !!

Typical the graphic reads sodom.

Re:TOO MANY IFS ANDS BUTTS !! (0)

Anonymous Coward | about 2 years ago | (#41892929)

No IFS ANDS BUTTS !!

No butts? Well, that's a relief!

Hypervisor leaks cached data (0)

Buttonius (31377) | about 2 years ago | (#41891831)

It appears that the hypervisor leaks data from one VM to another by not clearing a cache. If that is all, this leak can be fixed by explicitly clearing the cache when switching to another VM. This will probably cost a few CPU cycles (and cause a few extra cache misses when a VM is resumed).

Re:Hypervisor leaks cached data (3, Insightful)

gnasher719 (869701) | about 2 years ago | (#41891859)

It appears that the hypervisor leaks data from one VM to another by not clearing a cache.

What is leaked is not actually the data in the cache; another virtual machine running on the same computer cannot access that data. What is leaked is some information about cache usage, which may then allow an attacker to find out what the other VM has been doing. The attacker fills the cache with data, switches to another VM, and when it gets control again, the attacker measures how long it takes to access the data that it put into the cache itself. If it's fast, then the attacker knows that the other VM hasn't touched that part of the cache. If it's slow, the attacker knows that the other VM touched this part of the cache.

Re:Hypervisor leaks cached data (1)

camperdave (969942) | about 2 years ago | (#41893009)

If it's slow, the attacker knows that the other VM touched this part of the cache.

Um... no. It knows that the cache has been touched by another VM. There's no guarantee that it was the target VM.

Re:Hypervisor leaks cached data (0)

Anonymous Coward | about 2 years ago | (#41891881)

Before you know it processor vendors will start adding in multiple caches to reduce the amount of misses caused by switching between the VMs.
Eventually we end up where we started, with each VM running on it's own physical hardware.

Re:Hypervisor leaks cached data (1)

EmagGeek (574360) | about 2 years ago | (#41892063)

I doubt that. Pulling this attack off in an UNcontrolled environment will be damn near next to impossible, no matter how good these people think they are.

Modern clouds shuffle VM execution in realtime from hardware to hardware to hardware on a continuous basis, depending on where resources are available, and where they are in demand, at any given time.

In any case, a user's inability to use a system properly is not cause for AMD or Intel to run off and start changing their architecture. This "problem" is one that is incumbent upon the customers of the cloud service to fix, by not being stupid and putting national security stuff in the public cloud where it can be stolen.

Re:Hypervisor leaks cached data (2)

foniksonik (573572) | about 2 years ago | (#41892395)

Problem is that a leak of any PII data for customers of a business is a PR nightmare and potentially a largish lawsuit costing millions. Millions may be more than was saved by virtualizing.

Re:Hypervisor leaks cached data (2)

CastrTroy (595695) | about 2 years ago | (#41892763)

Millions aren't often saved by virtualizing your hardware. Almost all numbers I've seen show that the cost of running on virtual hardware is actually more costly than running on your own servers after you amortize the price of the servers over their lifespan. Often buying your own hardware pays for itself within a year. Hosting in the cloud makes sense in a small number of instances where you have wildly varying amounts of traffic and need to be able to scale up and scale down very quickly to big load changes. It also allows you to get some nice servers on day one without much capital investment. But that's not being very business smart. If the servers can pay for themselves in the first year, you should really be buying the servers. It can also be very cheap if you are utilizing almost no resources, but that is something I would consider more of a home project, and not something that is really something that business would be looking at.

Re:Hypervisor leaks cached data (0)

Anonymous Coward | about 2 years ago | (#41893333)

I'm not even convinced virtualizing saves any money. This is because you are concentrating mission critical things to a single piece of hardware, so that hardware has to be N times more reliable than a single standalone machine, and of course you have to buy two of them, because you really can't afford to lose _everything_.

If I have 10 servers that cost $N each, and I lose one of them, chances are I can get by still getting 90% of my work done until I can get back up and running. If I have 10 virtual servers running on one machine, then I certainly can't get by getting 0% of my work done, so I not only have to spend more than $10xN on ultra-reliable server hardware and the insanely-high cost of virtualization software licenses, but I have to spend it twice just to make certain I am never in a position to get 0% of my work done.

like everything, it depends on circumstances (1)

Chirs (87576) | about 2 years ago | (#41894049)

Suppose I have 4 build machines, each running a different OS or version of the OS. At any given time I only need to be building 1 version.

If I virtualize them, I can use one machine (with 4x the disk space). Even accounting for reliability (and getting better redundancy than before) I can get away with 2 machines instead of 4.

Re:Hypervisor leaks cached data (1)

mlts (1038732) | about 2 years ago | (#41895577)

It depends on the task at hand:

I have multiple virtual machines for various tasks, and it isn't just for security. It is also for separation of duties:

One VM runs Quickbooks. This is stored on a USB flash drive so I can do accounting on any machine, then physically lock up the drive when done. Unless a remote intruder is savvy enough to nail my machine while the VM is active, my Quickbooks data is fairly protected, since when it isn't in use, the external drive is stashed in a safe.

Another VM has Windows and some potential client information. I don't want this information to end up in my personal stuff, so it stays in the VM, and with the VM disks encrypted, all data stays protected regardless of where it sits.

A third VM is for anonymous Web browsing. It has sandboxie and other tools to make it difficult for malware to get out and about. Nothing is 100% secure, but unless there is a F0 0F like bug that can get something in ring 3 into ring 0 on x86, it does the job.

A fourth VM is used for Mozy/Carbonite/etc. It shares TrueCrypt volumes via CIFS which are mounted to other machines. This sounds roundabout, but it ensures that if the backup client got compromised, it wouldn't spread outside the VM, and the only data it works with is encrypted.

A fifth VM is what I use for GPG and documents. This is stashed on a USB flash drive, so when I'm done signing/decrypting files, the private keys are physically offline. Of course, a dedicated intruder can still get those, but it limits the avenues of attack.

VMs have a lot of advantages. I like using them for isolation so data done for a certain task stays in one place.

Re:Hypervisor leaks cached data (0)

Anonymous Coward | about 2 years ago | (#41900729)

VM isn't needed for isolation. If I worried about unsafe web browsing, I would simply log into another account for such activity. But my browser isn't vulnerable so why bother . . .

Re:Hypervisor leaks cached data (1)

mlts (1038732) | about 2 years ago | (#41901003)

It can be asserted that running under a user is good enough.

However, the advantage of VM level isolation is that everything related to a project (apps, data, even OS modifications) are stashed in one place. This can be done with users to a limited degree, but being able to have the complete OS with everything needed to run a specific application stored in one place is important. If done right, the VM doesn't care what hardware it runs on, so a future computer that might be ARM but translates x86 opcodes will be able to run the VM.

Then, there is the fact that malware can phone home. Having it only be able to access and report about a VM gives an attacker less info than if it is able to find what users a remote site possesses on its machines.

Re:Hypervisor leaks cached data (1)

cbhacking (979169) | about 2 years ago | (#41901697)

Wow, what browser do you use? You *might* be able to make an argument for netcat being secure, though I sure wouldn't bet on that. Firefox, Chrome, Opera, Safari, and IE have all had vulnerabilities discovered in the last year. Most of them were rapidly patched, and in some cases nobody other than the developers would ever have learned of the vulnerability if not for the patch notes, but I can guarantee you that they didn't find them all!

Also, logging into another account is insufficient. Just as your browser is vulnerable, so is your OS; I'm absolutely certain there are local EOP vulns in it somewhere. What good is logging into account B to protect account A when the exploit is running as root? Of course, the same argument could be made for VMs - once the guest machine is taken over, you're now trusting your hypervisor to keep your main OS from attacks, but there's probably some vuln in the hypervisor too (although this is a bit less likely than in a more complex piece of software like an OS). It goes on even further from there, too; attacks against the network, the hardware, your local power grid or ISP...

At some point, you simply must decide that there is *enough* security, and work from there. For most people, a fully-patched browser, preferably with Flash and Java disabled and possibly also JavaScript, running as a limited user with ideally some sandboxing around the browser process, is sufficient. That doesn't actually make you not vulnerable, though.

Re:Hypervisor leaks cached data (1)

mlts (1038732) | about 2 years ago | (#41894891)

Very true, but the burden of proof is on the victim. A PII loss really means nothing to a company other than a couple articles of bad press. Sony came out of the PSN compromise unscathed. Other companies have had break-ins, and they are not the worse for wear for the incidents, regardless of how things are handled.

The only organizations which actually would be held to task for break-ins would be government stuff. A private company losing data is considered normal. A government agency losing the same data will get people up in arms.

Re:Hypervisor leaks cached data (2, Interesting)

Anonymous Coward | about 2 years ago | (#41891899)

It appears that the hypervisor leaks data from one VM to another by not clearing a cache. If that is all, this leak can be fixed by explicitly clearing the cache when switching to another VM. This will probably cost a few CPU cycles (and cause a few extra cache misses when a VM is resumed).

The problem isn't data leaking but the change in latency to access memory when on the same cpu where a crypto algorithm is running. The keys can be reverse engineered if the crypto algorithm uses a well known table. There is no direct data leakage across VMs required. This is not a joke it is effective, but you have to get you VM onto the same server as the VM you are attacking. You can avoid the issue by using a dedicated server in the Amazon cloud case, or an Extra Large VM in Azure.

Detailed blog post (2, Interesting)

Anonymous Coward | about 2 years ago | (#41891893)

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

Nation-States? (0)

Anonymous Coward | about 2 years ago | (#41892045)

Why does everyone assume that the "Nation-State" is better at doing stuff like this than a private organization?

Remember, the best of the best don't work for government, because they can make much more money in the private sector, and the private sector has just as much motivation, if not more, to embark on this sort of activity than a Nation-State.

When I think of Nation-States, I think of incompetence, cutting corners, and operating under a set of political rules. I don't think of excellence and being the best in a field.

Re:Nation-States? (1)

fuzzyfuzzyfungus (1223518) | about 2 years ago | (#41892173)

A few factors come to mind:

1. The fact that certain not-officially-known nation states have pulled off highly sophisticated attacks is a matter of public knowledge.

2. A 'nation-state', as an entity that gets to collect taxes and is charged with assorted non-market processes like 'defense', has much broader ability to do things that make minimal financial sense. If you are worried about spammers, or PIN-skimmers, or whatnot it suffices to be more expensive to attack than your resources are worth. If you are in some clandestine entity's sights, you actually have to be hard, rather than simply uneconomic.

3. Even if (and this is far from obviously true) all state employees are a bunch of drooling idiots herded by ideological Kommisars, they always have the option of contracting the attack out to their private sector superiors. Plenty of contractors who specialize, or have a department specializing in, electronic attack tools and they'll hold your hand every step of the way if you cut them large enough checks.

need access to the host on which the vm is running (1)

dan_in_dublin (833271) | about 2 years ago | (#41892055)

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 if it would be a good thing to fix this problem, you pay for perf for web servers so disguising the computation to mitigate such an attack would cost way more than it would achieve

Easily fixed (1)

Chrisq (894406) | about 2 years ago | (#41892277)

just bind the cryptographically sensitive process to a dedicated processor.

Re:Easily fixed (1)

cbhacking (979169) | about 2 years ago | (#41901771)

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 target OSes decision to dedicate one CPU to the target process.

In fact, that actually makes the attacker's job a hell of a lot easier. They can dedicate their attack code to the same CPU, in which case *all* the cache changes that occur while the process is context-switched will be due to the target process. In a more typical environment, there would be a lot more "noise" in the cache activity.

Not Likely Reproducible in Production Environment (5, Informative)

Traiano (1044954) | about 2 years ago | (#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.

Re:Not Likely Reproducible in Production Environme (1)

rollingcalf (605357) | about 2 years ago | (#41892503)

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.

But that isn't nearly as exciting! (0)

Anonymous Coward | about 2 years ago | (#41892539)

Stop raining logic and reason when the sky is falling!

Re:Not Likely Reproducible in Production Environme (1)

foniksonik (573572) | about 2 years ago | (#41892709)

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).

Re:Not Likely Reproducible in Production Environme (1)

Hatta (162192) | about 2 years ago | (#41893015)

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 software is likely to be in use. AES on LUKS is a very common setup. Since multiple VMs are likely to be sharing the same hardware, this increases your chance of a hit.

Then you wait. Yes, it might take a while for the two VMs to coincide on the same CPU, but it will happen.

Paper Summary from an amateur perspective (0)

Anonymous Coward | about 2 years ago | (#41897317)

1. The Xen scheduler can be gamed and allows side-channel attacks.
2. Libgcrypt is not hardened against timing attacks and leaks information.
3. Signal processing is A Thing.

I have questions about entropy of VMs (0)

Anonymous Coward | about 2 years ago | (#41902129)

Speaking of side channel attacks ...

I have not done any formal experiments yet, but, according to the UNIX manual page for random(4), one of the sources for kernel entropy is hardware interrupts.

Because it's not clear to me that any hardware interrupts that exist, are truly random, in a virtualized machine ... it's not clear to me that VMs have the same level of randomness, as can be attained from interrupts occurring on an actual physical bus, servicing actual, diverse physical devices.

One workaround might be for the hypervisor to provide this from its own /dev/random but that would drain the hypervisor's pool of entropy more rapidly, weakening both hypervisor and virtual clients alike.

It would seem to me that the only robust solution to this would be for hypervisor motherboards to incorporate additional hardware, IE, a dedicated circuit that boosted the pool of entropy, say, monitoring the difference between the computer's internal and external temperatures - or background radiation, or something similarly unpredictable.

Or have I missed something?

~childo

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?