[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