Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

/dev/random and virtual systems

mail-archive.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: /dev/random and virtual systems

#21

Post by tptacek »

AretNCarlsen wrote: post #19
JoachimSchipper wrote: post #16

Earlier quoted context omitted.

Why do you feel a poll is useful?

I'm coming from a background in massively parallel computing and financial services, both of which are heavy on security. Nonetheless, and even though I have been running cryptographically active instances on Amazon and Rackspace for a long time, I had honestly never thought about the RNG source on VMs. That is my own failure, of course. I wonder, though, whether everyone else knew about the VM RNG issue, or if only…

You did not miss the memo. Crypto on virtualized cloud platforms isn't trustworthy. But it's a grade of untrustworthy several steps higher than "exploitable SQL injection", so people don't think about it, talk about it, or take it seriously.

The poll, though, is unnecessary and I flagged it.

Meanwhile, you brought up:

Robert Brown's dieharder: http://www.phy.duke.edu/~rgb/General/dieharder.php

NIST Statistical Test Suite: http://csrc.nist.gov/groups/ST/toolkit/rng/index.html

Fourmilab's ENT: http://www.fourmilab.ch/random/

You noted that people could run these on their CSPRNGs to check randomness. No, they can't. These are all useful tools indeed; pentesters use them to check cookies and crypto tokens. But they can only tell you whether bits are correlated. It is very easy for an uncorrelated stream of bits to be terribly insecure: they simply have to be seeded from the same source.

It is not a good idea to suggest people test their RNGs with things like "ent". In "ent", Ruby's insecure rand() can appear competitive with /dev/random.

There's also the obvious confounding issue with testing an entropy pool by depleting it.

Re: /dev/random and virtual systems

#22

Post by [deleted] »

AretNCarlsen wrote: post #19
JoachimSchipper wrote: post #16

Earlier quoted context omitted.

Why do you feel a poll is useful?

I'm coming from a background in massively parallel computing and financial services, both of which are heavy on security. Nonetheless, and even though I have been running cryptographically active instances on Amazon and Rackspace for a long time, I had honestly never thought about the RNG source on VMs. That is my own failure, of course. I wonder, though, whether everyone else knew about the VM RNG issue, or if only…

[deleted]

Re: /dev/random and virtual systems

#23

Post by jsprinkles »

JoachimSchipper wrote: post #15
tptacek wrote: post #10

Earlier quoted context omitted.

Here's a fine starting point: http://eprint.iacr.org/2006/351

For the benefit of everyone in a hurry: those attacks are very real. If you're running on AWS, assume that the NSA [EDIT: or anyone with deep pockets, or plenty of time on his hands] can break any crypto algorithm you use. You are still secure from script kiddies, of course, and you've done a fairly good job if this is the easiest way to hack you.

Citation for "real"? All of the papers I have read on the topic are theories and most every known side-channel attack is relatively benign and not specific to virtualization. Do you have evidence of a side-channel attack on Xen or KVM being performed successfully in the real world outside of an academic environment which led to cryptographic compromise?

It's easy to say things are "very real" when we don't know if the NSA can do them. Watch: mind control is very real. Assume the NSA has it.

Going from academic to accusing Amazon Web Services of intentionally exposing their customers to NSA side-channel attacks is libelous at best.

Re: /dev/random and virtual systems

#24

Post by jsprinkles »

tptacek wrote: post #17
JoachimSchipper wrote: post #15

Earlier quoted context omitted.

For the benefit of everyone in a hurry: those attacks are very real. If you're running on AWS, assume that the NSA [EDIT: or anyone with deep pockets, or plenty of time on his hands] can break any crypto algorithm you use. You are still secure from script kiddies, of course, and you've done a fairly good job if this is the easiest way to hack you.

This isn't NSA-hard stuff; it's $500,000-contract hard.

So what you're saying is that your fee for side-channeling the private keys from a neighboring domU or dom0 without root dom0 access is $500,000? How long to deliver?

Re: /dev/random and virtual systems

#25

Post by JoachimSchipper »

jsprinkles wrote: post #23
JoachimSchipper wrote: post #15

Earlier quoted context omitted.

For the benefit of everyone in a hurry: those attacks are very real. If you're running on AWS, assume that the NSA [EDIT: or anyone with deep pockets, or plenty of time on his hands] can break any crypto algorithm you use. You are still secure from script kiddies, of course, and you've done a fairly good job if this is the easiest way to hack you.

Citation for "real"? All of the papers I have read on the topic are theories and most every known side-channel attack is relatively benign and not specific to virtualization. Do you have evidence of a side-channel attack on Xen or KVM being performed successfully in the real world outside of an academic environment which led to cryptographic compromise? It's easy to say things are "very real" when we don't know if th…

[Edited in response to your repeated edits.]

VMs are bad because they make it much easier for an attacker to get a process on the same CPU as yours; nothing more, nothing less.

For VM-specific material, read e.g. http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf, in particular section 8.4, and note that keystroke timings are usually enough to recover plaintext (passwords are more difficult, but it should still give a good guess). The cache-based covert channel is interesting as well, mostly because it suggests that other cache-based attacks are possible.

Side-channel attacks work just fine outside of academic environments, but the people performing them are testers under NDA (consider Common Criteria for smart cards) or working for various intelligence agencies; they're unlikely to run their mouth on the internet.

Re: /dev/random and virtual systems

#26

Post by AretNCarlsen »

tptacek wrote: post #21
AretNCarlsen wrote: post #19

Earlier quoted context omitted.

I'm coming from a background in massively parallel computing and financial services, both of which are heavy on security. Nonetheless, and even though I have been running cryptographically active instances on Amazon and Rackspace for a long time, I had honestly never thought about the RNG source on VMs. That is my own failure, of course. I wonder, though, whether everyone else knew about the VM RNG issue, or if only…

You did not miss the memo. Crypto on virtualized cloud platforms isn't trustworthy. But it's a grade of untrustworthy several steps higher than "exploitable SQL injection", so people don't think about it, talk about it, or take it seriously. The poll, though, is unnecessary and I flagged it. Meanwhile, you brought up: Robert Brown's dieharder: http://www.phy.duke.edu/~rgb/General/dieharder.php NIST Statistical Test S…

Hence the caveat: "and hope/trust that the entropy you observe is unique, not copied to any other instances".

I suppose it would take a centralized web service to detect correlated unrandomness between servers. I am not personally willing to implement such a service right now.

Re: /dev/random and virtual systems

#27

Post by jsprinkles »

JoachimSchipper wrote: post #25
jsprinkles wrote: post #23

Earlier quoted context omitted.

Citation for "real"? All of the papers I have read on the topic are theories and most every known side-channel attack is relatively benign and not specific to virtualization. Do you have evidence of a side-channel attack on Xen or KVM being performed successfully in the real world outside of an academic environment which led to cryptographic compromise? It's easy to say things are "very real" when we don't know if th…

[Edited in response to your repeated edits.] VMs are bad because they make it much easier for an attacker to get a process on the same CPU as yours; nothing more, nothing less. For VM-specific material, read e.g. http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf , in particular section 8.4, and note that keystroke timings are usually enough to recover plaintext (passwords are more difficult, but it should still give a…

> VMs are bad because they make it much easier for an attacker to get a process on the same CPU as yours; nothing more, nothing less.

The paper cites less than 25% of the time which is specific to EC2. With more cores on the host this attack rapidly becomes impossible as domUs rarely share cores. Which is why I asked for actual evidence of cryptographic compromise in the wild and not yet more papers. You suffer from academia. Written in a paper and demonstrated to enable the same timing attacks that having network access enables (with reference to extracting passwords) does not mean "any cryptographic algorithm I use is compromised".

You said "assume the NSA can break your crypto". Since everybody likes to bang on EC2 I would like evidence of how that is accomplished since you used the words "very real". You bring up a good point in that if it is being done it is under NDA and, without realizing it, admitted that you have never heard of it being done.

Which begs the question: how can you say "very real"? Have you ever observed cryptographic compromise via a CPU side-channel exacerbated by virtualization or have you merely read about it?

At any rate, I look forward to your results in a couple of months after you side-channel a neighboring domU and compromise their crypto. Once you're ready I'll give you a couple of my own domUs to demonstrate on free of charge.

Re: /dev/random and virtual systems

#28

Post by tptacek »

jsprinkles wrote: post #24
tptacek wrote: post #17

Earlier quoted context omitted.

This isn't NSA-hard stuff; it's $500,000-contract hard.

So what you're saying is that your fee for side-channeling the private keys from a neighboring domU or dom0 without root dom0 access is $500,000? How long to deliver?

That is not what I'm saying, as you well know.

Re: /dev/random and virtual systems

#29

Post by jsprinkles »

tptacek wrote: post #28
jsprinkles wrote: post #24

Earlier quoted context omitted.

So what you're saying is that your fee for side-channeling the private keys from a neighboring domU or dom0 without root dom0 access is $500,000? How long to deliver?

That is not what I'm saying, as you well know.

Then who if not Matasano can perform such an attack for $500,000?

Let's say I'm in the market and this particular web site annoys me and it is hosted on EC2. I want to compromise that web site's crypto from a neighboring domU and my budget is $500,000.

You are saying I can contract with someone at that rate and it will get done? How long does that security company take to deliver? With your breadth of security experience and your claim that it's a $500,000-contract job surely you must know who will write that contract otherwise you wouldn't have said such a thing, right?

Re: /dev/random and virtual systems

#30

Post by tptacek »

jsprinkles wrote: post #27
JoachimSchipper wrote: post #25

Earlier quoted context omitted.

[Edited in response to your repeated edits.] VMs are bad because they make it much easier for an attacker to get a process on the same CPU as yours; nothing more, nothing less. For VM-specific material, read e.g. http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf , in particular section 8.4, and note that keystroke timings are usually enough to recover plaintext (passwords are more difficult, but it should still give a…

> VMs are bad because they make it much easier for an attacker to get a process on the same CPU as yours; nothing more, nothing less. The paper cites less than 25% of the time which is specific to EC2. With more cores on the host this attack rapidly becomes impossible as domUs rarely share cores. Which is why I asked for actual evidence of cryptographic compromise in the wild and not yet more papers. You suffer from…

To your last question: yes.

To your inevitable followup question: no, I'm not going to talk to you about it.

To your overarching point: if you are on a cloud platform that promises you will never share hardware with any other company – which virtually nobody is – you are still at greater risk simply being on a nanosecond-timeable switched network with your attackers. But local crypto timing attacks are far more powerful.

Nobody bothers with this stuff because simple application-layer attacks are so simple that there's little impetus to develop and mainstream the attack techniques to exploit them. You're naive indeed if you think that's a gauge of how practical those attacks are.

I wonder where your stridency on this topic comes from. I've read all your comments here --- I mean all of them, on HN period --- and I haven't been able to discern what background you might have in software crypto security. You're here saying something that contradicts virtually every other software crypto person I know, is why I wonder.

You talked earlier about "all the papers you read being theoretical" (I'm paraphrasing). What papers would those be? Because I'm a little familiar with this research (we pirated it gleefully for our virtualized rootkit detection talk several years ago), and, relative to the crypto literature at large, x86 side channel research is striking in how non- theoretical it is; to wit: most crypto papers don't come with exploit testbed how-tos.

Post reply on HN