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

Måns Rullgård mans
Wed Jun 30 22:07:40 CEST 2010


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.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list