svn commit: r241373 - head/lib/libc/stdlib

[Kevin Lo]

On 2012/10/12 03:50, Eitan Adler wrote:
> On 11 October 2012 07:44, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
>> On Tue, Oct 09, 2012 at 01:51:05PM -0400, Eitan Adler wrote:
>>> On 9 October 2012 13:27,  <mdf at freebsd.org> wrote:
>>>> The original behavior can be recovered by using inline assembly to
>>>> fetch the value from a register into a local C variable; this would at
>>>> least not rely on undefined behavior.  But I agree it's of dubious
>>>> value anyways.
>>> I proposed this (with a patch). We want to move to not using
>>> /dev/random and instead make a kernel system call directly. The patch
>>> for this is not finished yet though.
>> You should do something similar to:
>>
>>          http://people.freebsd.org/~pjd/patches/libc_arc4random.c.patch
> Yes, this is exactly the proposed "correct" fix. I haven't had time to
> properly write and test such a patch though, so I opted for this one
> in the meantime.
>
> FWIW, the man page *used* to contain the text
>
>       The srandomdev() routine initializes a state array using the random(4)
>       random number device which returns good random numbers, suitable for
>       cryptographic use.
>
> which made this problem 'worse' as it mislead people into believing
> rand/random could be used for crpyto.
>
> des@ fixed this problem already
As you may already know, this issue was pointed out by Xi Wang in his paper
"Undefined Behavior: Who Moved My Code?" at APSYS 2012 conference:
http://apsys2012.kaist.ac.kr/media/papers/apsys2012-final42.pdf

The bottom line is don't use uninitialized memory as a source of entropy :-)

     Kevin