[FFmpeg-devel] [PATCH] Make av_get_random_seed not block when waiting for more entropy

[Michael Niedermayer]

On Wed, Jun 30, 2010 at 11:54:05PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Wed, Jun 30, 2010 at 10:20:29PM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Wed, Jun 30, 2010 at 09:53:55PM +0100, M?ns Rullg?rd wrote:
> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> 
> >> >> > On Wed, Jun 30, 2010 at 09:07:40PM +0100, M?ns Rullg?rd wrote:
> >> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> >> 
> >> >> >> > On Wed, Jun 30, 2010 at 07:28:16PM +0300, Martin Storsj? wrote:
> >> >> >> >> On Wed, 30 Jun 2010, M?ns Rullg?rd wrote:
> >> >> >> >> 
> >> >> >> >> > Martin Storsj? <martin at martin.st> writes:
> >> >> >> >> > 
> >> >> >> >> > > On Wed, 30 Jun 2010, Michael Niedermayer wrote:
> >> >> >> >> > >
> >> >> >> >> > >> before you spend more time on this.
> >> >> >> >> > >> There is a possible security issue with using non block mode
> >> >> >> >> > >> namely if we have /dev/*random and not use it we can end up
> >> >> >> >> > >> using a uninitialized variable. Thats an information leak
> >> >> >> >> > >> it could leak from pointers (kills ASLR) to OS/platform or
> >> >> >> >> > >> compiler version or or or ...
> >> >> >> >> > >> thats all usefull information for a attacker
> >> >> >> >> > >> he only has to saturate /dev/random so it would block
> >> >> >> >> > >
> >> >> >> >> > > Could you elaborate on your concern here? The fix he committed tries
> >> >> >> >> > > both /dev/random and /dev/urandom, and the latter should never block
> >> >> >> >> > > (afaik), and even in that case I don't see where any uninitialized
> >> >> >> >> > > variable would be leaked?
> >> >> >> >> > 
> >> >> >> >> > If neither of the files exist, or only /dev/random exists and blocks,
> >> >> >> >> > it will return an uninitialised value.  It changes only on systems
> >> >> >> >> > that have a blocking /dev/random and no /dev/urandom.
> >> >> >> >> 
> >> >> >> >> True, except that we'd use AV_READ_TIME in the not all that rare cases 
> >> >> >> >> where it is defined. But for that case where it isn't, what about trying 
> >> >> >> >> /dev/random in blocking mode only if both the others have failed in 
> >> >> >> >> nonblocking mode?
> >> >> >> >
> >> >> >> > possible
> >> >> >> >
> >> >> >> > though maybe we could simplify this by asking which combinations actually
> >> >> >> > exist?
> >> >> >> 
> >> >> >> Given that systems without any of the /dev files certainly exist, we
> >> >> >> definitely need a sensible fallback for this case.  AV_READ_TIME is
> >> >> >> only defined for a few arches.
> >> >> >
> >> >> > i wonder if systems with a blocking random and no urandom
> >> >> > exist because if not we dont need the non blocking code. We can just
> >> >> > do blocking reads
> >> >> 
> >> >> That doesn't address the question of what to do when both of them
> >> >> fail to deliver, whether through blocking or nonexistence.
> >> >
> >> > no it doesnt address that question. Thats no reason though not to
> >> > adress the other question
> >> 
> >> You're trying really hard to avoid it...  My question must be answered
> >> whatever the answer to yours is.  The converse is not true.
> >
> > Nothing must be awnsered and there is no such relation between the questions
> > as you pretend there is.
> >
> > Anyway, if nothing is available to generate a random number then the only
> > sane thing to do is to return 0
> > it is certainly better than returning uninitialized memory.
> 
> You _are_ stubborn.

I dont want to leave messy code in svn if it can be improved.


> There are systems, many in fact, without
> /dev/[u]random or AV_READ_TIME.

yes but the question was about 
blocking /dev/random and non existing /dev/urandom at the same time.
(or a unrealistic blocking /dev/urandom)


open(/dev/urandom)
if(fail)
    open(/dev/random)
read()

is sufficient if such system does not exist

also the non blocking code you implemented has a much more dangerous failure
mode. Because if one is skiped due to blocking and the other is as well or
doesnt exist a significantly worse and currently possibly exploitable value
is returned.

My example above will just block in this case, its thus inherently more secure
besides being much simpler

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100701/3a643470/attachment.pgp>