[MPlayer-dev-eng] Fwd: [MPlayer-users] Mplayer exploit?!

[D Richard Felker III]

On Tue, Jan 14, 2003 at 06:42:37PM +0100, Arpi wrote:
> Hi,
> 
> > While this is a fake now, IMHO it's very good for us to be looking.
> I said the same...
> 
> > I've been saying for a long time that mplayer is probably full of
> > exploitable code, especially in the demuxers and possibly libmpeg2.
> 
> libmpeg2 is safe. it has boundary checks around writes, and has sig11
> trap for illegal reads. but it's the only safe codec, imho.

The sig11's are what make me suspicious, but if that's the case I
guess they're ok.

> the most possible overflows are in demuxers, especially in real, asf,
> maybe mov, and the other overcomplicated ones.
> mpeg is safe imho, and probably avi too.

Agree.

> also several codecs are optimized for speed, the price is missing boundary
> checks. mp3lib is a good example of that...  maybe libavcodec too.

mp3lib is quite broken IMO, but it's fast and "good enough" most of
the time. I have quite a few audio mp3 files that it puts nasty pops
and stuff in. MAD seems to be the best quality decoder.

> and the biggest place: configfile & subtitles & playlists parsers.

Configfile is a non-issue IMO since it's specified by the user running
mplayer. If you want to 'exploit' your own mplayer process with a
bogus config file thats your business. :))

> while we can fix demuxers & text parsers easily, fixing codecs may cause
> big speed loss.

I really doubt that. They can't be using any sort of far-reaching
pointers/large offsets since that would waste lots of space, so the
worst case is probably pointers being off by +- 64k. This can be fixed
by putting the bitstream in its own mmaped buffer away from everything
else. :) Decoded frame mpi's could also go in their own mmaps except
for the DR case (when they're in video memory or shared memory
segments anyway so already outside the normal address range).

But seriously, I imagine that in most cases the necessary boundary
checks wouldn't significantly impact performance. It's probably worth
checking fixing them properly and at least making it a compiletime
option.

Rich