[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:01.random

[Alan Somers]

On Wed, Jan 15, 2014 at 11:53 AM, Darren Pilgrim
<list_freebsd at bluerosetech.com> wrote:
> 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.

By compromising it at the design stage.  For example, the NSA could
hypothetically collaborate with Intel to trojan Intel's RNG.  In that
case, the NSA would've compromised the RNG, but they wouldn't have
unfettered access to the rest of the system.

>
>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"