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

11–20 of 42 posts

Re: /dev/random and virtual systems

#11

Post by JonnieCache »

tptacek wrote: post #10
JonnieCache wrote: post #9

Earlier quoted context omitted.

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?

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

thanks

Re: /dev/random and virtual systems

#12

Post by yuhong »

tptacek wrote: post #4
stipes wrote: post #2

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

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.

Not to mention that if you let untrusted people control VMs on the host side, you have bigger problems than this attack.

Re: /dev/random and virtual systems

#13

Post by yuhong »

stipes wrote: post #8
tptacek wrote: post #4

Earlier quoted context omitted.

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.

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.

How about having a command to manually reseed the PRNG?

Re: /dev/random and virtual systems

#15

Post by JoachimSchipper »

tptacek wrote: post #10
JonnieCache wrote: post #9

Earlier quoted context omitted.

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?

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.

Re: /dev/random and virtual systems

#17

Post by tptacek »

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.

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

Re: /dev/random and virtual systems

#18

Post by JoachimSchipper »

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.

Or "nice paper" hard, really. In fact, I'm pretty sure that I could convince my advisor to let me work on such an attack, and I think I could pull it off in a couple of months. It's hardly novel at this point, though.

Good point, though; I've edited my comment.

Re: /dev/random and virtual systems

#19

Post by AretNCarlsen »

JoachimSchipper wrote: post #16
AretNCarlsen wrote: post #14

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

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

Re: /dev/random and virtual systems

#20

Post by tptacek »

yuhong wrote: post #13
stipes wrote: post #8

Earlier quoted context omitted.

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.

How about having a command to manually reseed the PRNG?

You mean like write(2)? :)
Post reply on HN