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

[Stefano Sabatini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attack-proof-ffserver.patch
Type: text/x-diff
Size: 681 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090106/6e9706ce/attachment.patch>