[FFmpeg-devel] [PATCH] Make av_get_random_seed not block when waiting for more entropy
Wed Jun 30 22:02:42 CEST 2010
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?
though maybe we could simplify this by asking which combinations actually
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel