[FFmpeg-devel] AVRandomState usage in ffserver/RTP/RTSP

[Stefano Sabatini]

On date Tuesday 2009-01-06 22:50:44 +0100, Stefano Sabatini encoded:
> On date Monday 2009-01-05 13:30:40 -0800, Baptiste Coudurier encoded:
> > Hi,
> > 
> > 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.
> 
> Regards.
> -- 
> FFmpeg = Faboulous & Fostering Mortal Pitiless Efficient Gem

> Index: ffmpeg/ffserver.c
> ===================================================================
> --- ffmpeg.orig/ffserver.c	2009-01-05 17:24:43.000000000 +0100
> +++ ffmpeg/ffserver.c	2009-01-05 17:31:35.000000000 +0100
> @@ -4468,6 +4468,7 @@
>  int main(int argc, char **argv)
>  {
>      struct sigaction sigact;
> +    struct timeval tv;
>  
>      av_register_all();
>  
> @@ -4483,7 +4484,8 @@
>  
>      unsetenv("http_proxy");             /* Kill the http_proxy */
>  
> -    av_random_init(&random_state, av_gettime() + (getpid() << 16));
> +    gettimeofday(&tv, NULL);
> +    av_random_init(&random_state, tv.tv_usec);
>  
>      memset(&sigact, 0, sizeof(sigact));
>      sigact.sa_handler = handle_child_exit;

Ping?

Regards.
-- 
FFmpeg = Foolish & Fundamental MultiPurpose Elastic Game