[FFmpeg-devel] AVRandomState usage in ffserver/RTP/RTSP
Tue Jan 6 22:50:44 CET 2009
On date Monday 2009-01-05 13:30:40 -0800, Baptiste Coudurier encoded:
> Michael Niedermayer wrote:
> > On Mon, Jan 05, 2009 at 05:32:50PM +0100, Stefano Sabatini wrote:
> >> On date Monday 2009-01-05 17:00:50 +0100, Michael Niedermayer
> >> encoded:
> >>> On Mon, Jan 05, 2009 at 02:44:34AM +0100, Stefano Sabatini wrote:
> >>> [...]
> >>>> Index: ffmpeg/ffserver.c
> >>>> ===================================================================
> >>>> --- ffmpeg.orig/ffserver.c 2009-01-05 02:40:48.000000000 +0100
> >>>> +++ ffmpeg/ffserver.c 2009-01-05 02:41:00.000000000 +0100 @@
> >>>> -4483,7 +4483,7 @@
> >>>> unsetenv("http_proxy"); /* Kill the http_proxy */
> >>>> - av_init_random(av_gettime() + (getpid() << 16),
> >>>> &random_state); + av_random_init(&random_state, av_gettime()
> >>>> + (getpid() << 16));
> >>>> memset(&sigact, 0, sizeof(sigact)); sigact.sa_handler =
> >>>> handle_child_exit;
> >>> do we really have to export the pid and starttime to an attacker?
> >> Would be this more acceptable?
> > open /dev/random/ read into the seed if either fails use 0. thats
> > IMHO ... iam not ffserver maintainer, and dont even know why ffserver
> > needs random numbers.
This will fail if /dev/random is not accessible, in that case every
RTP stream will have the same session id, and this is troublesome.
> Apparently ffserver needs random data for RTSP/RTP session id. Not
> really sure if random is really needed, more probably unique number,
> IIRC this was discussed before but Im not RTSP/RTP expert.
>From RFC 1889:
| Synchronization source (SSRC): The source of a stream of RTP packets,
| identified by a 32-bit numeric SSRC identifier carried in the
| RTP header so as not to be dependent upon the network address.
| All packets from a synchronization source form part of the same
| timing and sequence number space, so a receiver groups packets
| by synchronization source for playback. Examples of
| synchronization sources include the sender of a stream of
| packets derived from a signal source such as a microphone or a
| camera, or an RTP mixer (see below). A synchronization source
| may change its data format, e.g., audio encoding, over time. The
| SSRC identifier is a randomly chosen value meant to be globally
| unique within a particular RTP session (see Section 8). A
| participant need not use the same SSRC identifier for all the
| RTP sessions in a multimedia session; the binding of the SSRC
| identifiers is provided through RTCP (see Section 6.4.1). If a
| participant generates multiple streams in one RTP session, for
| example from separate video cameras, each must be identified as
| a different SSRC.
While I'm not an RTP/RTSP expert too I think the patch attached makes
ffserver not provide useful informations to an eventual attacker, or
at least improves the current behaviour.
FFmpeg = Faboulous & Fostering Mortal Pitiless Efficient Gem
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 681 bytes
Desc: not available
More information about the ffmpeg-devel