7 ms·

/dev/random and virtual systems

48 points by bobds 15y ago

stipes 15y ago
I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cseweb.ucsd.edu/~syilek/ndss2010.html http://cseweb.ucsd.edu/~syilek/ndss2010.html
- tptacek 15y ago
  That's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.
  - stipes 15y ago
    Part of the problem is the conflict of transparency and security here. Fixing the wholesale reuse of RNG state would most likely require modifying the guest so that it is aware of being restarted from a snapshot so it can react appropriately. However, that might have consequences on what restoring from a snapshot means conceptually.
    - yuhong 15y ago
      How about having a command to manually reseed the PRNG?
      - tptacek 15y ago
        You mean like write(2)? :)
        stipes 15y ago
        Yes, in general write to /dev/random with the write permissions is how entropy gathering daemons and the like work. It gets added the input and mixed in. However, that doesn't fix the issue of how a snapshot restore works on most hypervisors. Adding an RNG refresh as part of the restore process could be possible, but definitely not trivial, and it could have other consequences if not carefully implemented.
  - yuhong 15y ago
    Not to mention that if you let untrusted people control VMs on the host side, you have bigger problems than this attack.
justincormack 15y ago
Most servers have little source of decent entropy. Virtualisation makes this worse. Intel has dropped the motherboard RNG support in their chipsets. The suggestion in the thread to use a few cheap VIA boxes which have CPU RNG is one idea. There are cheap USB rngs too like http://www.entropykey.co.uk/ http://www.entropykey.co.uk/.
tptacek 15y ago
There are even bigger concerns with crypto on virtualized hardware: side channels. We probably don't even know all the microarchitectural pathways that crypto code can leave footprints on, let alone how to deploy efficient general-purpose crypto code to obscure those footprints.
- JonnieCache 15y ago
  Could you elaborate on this? My interesting stuff detector is going crazy but I'm kinda out of my depth as to what exactly you're talking about. Are you referring to information leakage from the guest to the host operating system that might allow the host to sniff the inner workings of crypto algorithms running on the guest? Or perhaps guests sniffing other guests through timing attacks and suchlike?
  - tptacek 15y ago
    Here's a fine starting point: http://eprint.iacr.org/2006/351 http://eprint.iacr.org/2006/351
    - JonnieCache 15y ago
      thanks
    - JoachimSchipper 15y ago
      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.
      - tptacek 15y ago
        This isn't NSA-hard stuff; it's $500,000-contract hard.
ScottBurson 15y ago
In a previous job I worked for a company whose product needed some entropy on startup. It originally read from /dev/random. But then one of our customers reported that the product was hanging on startup, just after installation. It turned out that they had installed it into a freshly built VM (not a cloned one, I guess) and the read from /dev/random was waiting to accumulate enough entropy to return. (We changed it to use /dev/urandom instead, which is not entirely satisfactory, but at least prevents hanging in this situation.) While this is not exactly the scenario the OP is describing, it's another thing that can go wrong with /dev/random and VMs.
- nodata 15y ago
  But that's not a problem with /dev/random and VMs, that's a problem everywhere.
  - eru 15y ago
    But most bare-metal installations will only hang once.
- cpeterso 15y ago
  For servers and VMs without much internal entropy, they could use a random number server. On boot, they could pull random seed data from a web service like random.org or by hashing Google News headlines.
AretNCarlsen 15y ago
I put up a poll on the subject: http://news.ycombinator.com/item?id=2597256 http://news.ycombinator.com/item?id=2597256
- JoachimSchipper 15y ago
  Why do you feel a poll is useful?
  - AretNCarlsen 15y ago
    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 I had missed the memo. If the majority of poll respondents have never thought about the problem at all, perhaps I should start an awareness campaign on wikis and forums.
    - tptacek 15y ago
      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 http://www.phy.duke.edu/~rgb/General/dieharder.php NIST Statistical Test Suite: http://csrc.nist.gov/groups/ST/toolkit/rng/index.html http://csrc.nist.gov/groups/ST/toolkit/rng/index.html Fourmilab's ENT: http://www.fourmilab.ch/random/ 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.

48 points by bobds 15y ago

I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cseweb.ucsd.edu/~syilek/ndss2010.html http://cseweb.ucsd.edu/~syilek/ndss2010.html

tptacek 15y ago
That's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.
- stipes 15y ago
  Part of the problem is the conflict of transparency and security here. Fixing the wholesale reuse of RNG state would most likely require modifying the guest so that it is aware of being restarted from a snapshot so it can react appropriately. However, that might have consequences on what restoring from a snapshot means conceptually.
  - yuhong 15y ago
    How about having a command to manually reseed the PRNG?
    - tptacek 15y ago
      You mean like write(2)? :)
      - stipes 15y ago
        Yes, in general write to /dev/random with the write permissions is how entropy gathering daemons and the like work. It gets added the input and mixed in. However, that doesn't fix the issue of how a snapshot restore works on most hypervisors. Adding an RNG refresh as part of the restore process could be possible, but definitely not trivial, and it could have other consequences if not carefully implemented.
- yuhong 15y ago
  Not to mention that if you let untrusted people control VMs on the host side, you have bigger problems than this attack.

justincormack 15y ago

Most servers have little source of decent entropy. Virtualisation makes this worse. Intel has dropped the motherboard RNG support in their chipsets. The suggestion in the thread to use a few cheap VIA boxes which have CPU RNG is one idea. There are cheap USB rngs too like http://www.entropykey.co.uk/ http://www.entropykey.co.uk/.

tptacek 15y ago

There are even bigger concerns with crypto on virtualized hardware: side channels. We probably don't even know all the microarchitectural pathways that crypto code can leave footprints on, let alone how to deploy efficient general-purpose crypto code to obscure those footprints.

JonnieCache 15y ago
Could you elaborate on this? My interesting stuff detector is going crazy but I'm kinda out of my depth as to what exactly you're talking about. Are you referring to information leakage from the guest to the host operating system that might allow the host to sniff the inner workings of crypto algorithms running on the guest? Or perhaps guests sniffing other guests through timing attacks and suchlike?
- tptacek 15y ago
  Here's a fine starting point: http://eprint.iacr.org/2006/351 http://eprint.iacr.org/2006/351
  - JonnieCache 15y ago
    thanks
  - JoachimSchipper 15y ago
    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.
    - tptacek 15y ago
      This isn't NSA-hard stuff; it's $500,000-contract hard.

ScottBurson 15y ago

In a previous job I worked for a company whose product needed some entropy on startup. It originally read from /dev/random. But then one of our customers reported that the product was hanging on startup, just after installation. It turned out that they had installed it into a freshly built VM (not a cloned one, I guess) and the read from /dev/random was waiting to accumulate enough entropy to return. (We changed it to use /dev/urandom instead, which is not entirely satisfactory, but at least prevents hanging in this situation.) While this is not exactly the scenario the OP is describing, it's another thing that can go wrong with /dev/random and VMs.

nodata 15y ago
But that's not a problem with /dev/random and VMs, that's a problem everywhere.
- eru 15y ago
  But most bare-metal installations will only hang once.
cpeterso 15y ago
For servers and VMs without much internal entropy, they could use a random number server. On boot, they could pull random seed data from a web service like random.org or by hashing Google News headlines.

AretNCarlsen 15y ago

I put up a poll on the subject: http://news.ycombinator.com/item?id=2597256 http://news.ycombinator.com/item?id=2597256

JoachimSchipper 15y ago
Why do you feel a poll is useful?
- AretNCarlsen 15y ago
  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 I had missed the memo. If the majority of poll respondents have never thought about the problem at all, perhaps I should start an awareness campaign on wikis and forums.
  - tptacek 15y ago
    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 http://www.phy.duke.edu/~rgb/General/dieharder.php NIST Statistical Test Suite: http://csrc.nist.gov/groups/ST/toolkit/rng/index.html http://csrc.nist.gov/groups/ST/toolkit/rng/index.html Fourmilab's ENT: http://www.fourmilab.ch/random/ 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.