Date: Wed, 15 Jan 2014 10:53:51 -0800 From: Darren Pilgrim <list_freebsd@bluerosetech.com> To: Mike Tancsa <mike@sentex.net>, freebsd-stable@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:01.random Message-ID: <52D6D93F.7020600@bluerosetech.com> In-Reply-To: <52D6D5C7.80200@sentex.net> References: <201401142011.s0EKBoi7082738@freefall.freebsd.org> <52D6BF9C.8070405@bluerosetech.com> <52D6D5C7.80200@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/15/2014 10:39 AM, Mike Tancsa wrote: > On 1/15/2014 12:04 PM, Darren Pilgrim wrote: >> >> 1. If you're on "bare metal", the attacker has firmware-level or >> physical access to the machine; >> 2. If you're on a hypervisor, you can't trust the hypervisor; >> >> In both cases, I would think the attacker can use much simpler, more >> direct vectors and you have much worse things to worry about than the >> quality of /dev/random. I'm not questioning the validity of the >> advisory, I'm genuinely curious about this. I can't think of a scenario >> were someone could attack /dev/random using this vector without 1 or 2 >> above also being true. > > Say you have a physical tap on the network upstream from the victim. The > victim is exchanging data across a VPN. You can capture the encrypted > traffic, and knowing there is a weakness in the quality of RNG, more > easily decode the encrypted traffic. You dont have to worry about > sending "extra" traffic from the host say, by poking around in /dev/mem > etc. Yes, that's an obvious consequence of a compromised RNG; but that's not what I was asking. I'm asking how the attacker could compromise the hardware RNG without also obtaining effectively unfettered access to the entire system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D6D93F.7020600>