[FFmpeg-devel] Correctly fill the SSRC field in RTP packets

[Michael Niedermayer]

On Tue, Mar 25, 2008 at 06:27:53PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 25, 2008 at 01:58:47PM +0100, Luca Abeni wrote:
> > Hi all,
> >
> > I've just realized that the RTP muxer currently fills the
> > SSRC field in RTP packets with 0, generating multiple RTP
> > streams with the same SSRC. Unless I misread RFC3550, this
> > is not ok, since different streams in the same session
> > should have different SSRCs.
> >
> > The attached patch fills the SSRC field using the address
> > of the AVFormatContext, so that different streams in the
> > same session will have different SSRCs. I am posting the
> > patch instead of directly committing it because I do not
> > know if using the AVFormatContext address could be a problem
> > for security, or if there is some other drawback. If noone
> > objects, I'll commit the patch in 2 or 3 days.
> [...]
> > @@ -60,7 +60,7 @@
> >      s->base_timestamp = 0; /* FIXME: was random(), what should this be? */
> >      s->timestamp = s->base_timestamp;
> >      s->cur_timestamp = 0;
> > -    s->ssrc = 0; /* FIXME: was random(), what should this be? */
> > +    s->ssrc = (int)s;
> 
> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
> insanity ...
> you are leaking information VERY usefull for an exploit.
> and no whatever_random_number_generator(seed=(int)s) is equally bad for the
> exact same reason.

To explain why exactly this is bad, think of grsec which amongth other things
randomizes the location of the heap. Leaking any address of any malloc()
struct leaks this address unless you have a libc which randomizes the heap
at finer granularity (= not gnu libc AFAIK).
Why does the heap location help a exploit?
Well if you overwrite the internal structs gnu libc malloc() places between
malloced() blocks then you can get a free() call of that block
to overwrite any choosen adderss with any choosen 32bit value. Think of
overwriting a function ptr on the heap here, like one in AVFormatContext
if this doesnt sound scary, think of overwriting the ptr with the address
of system().

Thus this might help to exploit heap overflows IMHO. But even if my
explanation above has a bug its still a very bad idea to leack addresses
of things ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080325/ee244c08/attachment.pgp>