Bugzilla Bug 89277

As stated on the official mplayer homepage there are two head overflows.
Fixes are available for download on the homepage. I will attach the ported
patches.
Interestingly, they write about a pre7 version on the homepage, but it's not
officially been released yet.


Reproducible: Always
Steps to Reproduce:

Created an attachment (id=56428) [details]
Real RTSP heap overflow patch

Created an attachment (id=56429) [details]
MMST heap overflow patch

2005.04.16, Saturday :: MMST heap overflow
posted by Roberto
Summary

A potential buffer overflow was found and fixed in code used to handle MMST streams.
Severity

High (arbitrary remote code execution under the user ID running the player) when streaming MMS/TCP data from a malicious server, null if you do not use this feature. At this time there is no known exploit.
Description

While enumerating streams from a server, MMST code stores stream IDs in a fixed length array, but there is no check to stop the process if too many stream IDs are received. A malicious server could announce more than 20 streams and overflow the array.
Solution

A fix for the vulnerability was checked into MPlayer CVS on Fri Apr 15 23:31:57 2005 UTC. Users of affected MPlayer versions should upgrade to an unaffected MPlayer version. Alternatively a patch is available that can be applied to the MPlayer source tree.
Affected versions

MPlayer 1.0pre6 and before (including pre6a)
Unaffected versions

MPlayer 1.0pre7 and after
CVS HEAD after Fri Apr 15 23:31:57 2005 UTC

=====================

 2005.04.16, Saturday :: Real RTSP heap overflow
posted by Roberto
Summary

A potential buffer overflow was found and fixed in code used to handle RealMedia RTSP streams.
Severity

High (arbitrary remote code execution under the user ID running the player) when streaming RTSP data from a malicious server, null if you do not use this feature. At this time there is no known exploit.
Description

While getting lines from a server, Real RTSP code stores them in a fixed size array of MAX_FIELDS elements, but there is no check to stop the process if too many lines are received. A malicious server could send more than MAX_FIELDS lines and overflow the array. Since the array holds pointers to answer strings, an attacker cannot write arbitrary data into it, making an exploit more difficult.
Solution

A fix for the vulnerability was checked into MPlayer CVS on Fri Apr 15 23:30:44 2005 UTC. Users of affected MPlayer versions should upgrade to an unaffected MPlayer version. Alternatively a patch is available that can be applied to the MPlayer source tree.
Affected versions

MPlayer 1.0pre6 and before (including pre6a)
Unaffected versions

MPlayer 1.0pre7 and after
CVS HEAD after Fri Apr 15 23:30:44 2005 UTC

media-video, please bump/patch/comment

mplayer-1.0_pre5-r5 is the latest stable version for most architectures. we
could apply the patches to mplayer-1.0_pre6* and then we should aim to mark
mplayer-1.0_pre6-r1 stable. mplayer related problems which came in lately were
related to -r2. when -pre7 will be released we could integrate it via the
normal procedur into the tree (with the 30 day testing period etc) before going
into stable.

patches are now in the tree, mplayer-1.0_pre6-r{1,2,3} apply them. we should
mark -r1 stable, afterwards _pre5 can be removed.

ok, done. now we should mark mplayer-1.0_pre6-r4 stable. changed the following
things:

mplayer-1.0_pre6-r1 -> mplayer-1.0_pre6-r4
mplayer-1.0_pre6-r2 -> mplayer-1.0_pre6-r5
mplayer-1.0_pre6-r3 -> mplayer-1.0_pre6-r6

Arches, please test mplayer-1.0_pre6-r4 and mark stable

done for amd64 and x86

Stable on ppc.

*** Bug 89384 has been marked as a duplicate of this bug. ***

stable on ppc64

Stable on SPARC.

GLSA drafted, security pls review

alpha, pls mark test and mark stable if possible

Stable on alpha.

GLSA 200504-19

thanks everyone