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

[Arpi]

Hi,

> > libmpeg2 is safe. it has boundary checks around writes, and has sig11
> > trap for illegal reads. but it's the only safe codec, imho.
> 
> If sig11 traps are necessary that only shows that there is in fact a problem.
> A working exploit won't trigger a seg fault. Sig11 traps only hide the
> problem, they don't actually fix it.

no. they nor fix nor hide it.
they workaround it.

> You only get a sig11 if you read or write to unallocated memory, security
yes.

it was a long discussion 2 years ago on the mpeg2-dev list.
we got to the conclusion, that write pointers must be boundary checked.
actually there is only one write counter: the ES buffer.
it's easy to check and doesn't cause speed loss.

while there are reads at motion compensation, and at the bitstream parser
(buffer end).

libmpeg2 doesn't have checks for source address for motion compensation,
instead there is a sig11 trap, ie. a sighandler for signal 11, and a longjmp
to the parser's error concealment code.
we won about 8% cpu usage with that trick, remember that libmpeg2 is heavily
optimized for cpu cache usage (both l1 & l2).

this is tricky, but not a bad solition. imho it's a nice trick, and the
fastest possible solution of the problem.

btw latets libmpeg2 has new MC approach, and has checks for MC src range
too, so the sig11 trap is not needed any mroe (once we upgrade libmpeg2 in
mplayer, unfortunatelly we can't since new libmpeg2 api lacks some major
things we need)

> exploits work by stuffing extra data past the end of valid allocations into
i know what are exploits!

> more allocated space. Usually this is in stack allocations to overwrite the
> stack frame with the return address.

understand please that writes are boundary checked, only reads from frame
memory isn't protected. it can't be used for exploit.

> The only way to make code safe is to actually keep all memory accesses within
> the allocated bounds. Unfortunately this will be hard or impossible to
== big speed loss

> guarantee for the external dlls, especially the win32 dlls.
sure.

> The only way to guarantee safety for those would be to run the code under an
> emulator like valgrind. But that would have prohibitive performance problems.
sure.

look, we're developing the fastest movie player in the linux world, and not
the most secure movie player of the world.

feel free to fork() the project and create a paranoid version...
and please read my mail and also understand before answering nonsenses.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu