Bugzilla Bug 49387

Summary: 
 Multiple vulnerabilities have being found and fixed in the Real-Time Streaming Protocol (RTSP) client for RealNetworks servers, including a series of potentially remotely exploitable buffer overflows. This is a joint advisory by the MPlayer and xine teams as the code in question is common to these projects. The xine team has assigned ID XSA-2004-3 to this security announcement. 
 
Severity: 
 High (arbitrary remote code execution under the user ID running the player) when playing Real RTSP streams. At this time, there is no known exploit for these vulnerabilities. 
 
Prerequisites: 
 The players are only vulnerable when playing Real RTSP streams. There is no risk if Real RTSP (realrtsp) streaming is not employed. 
 
Solution: 
 A fix was checked into MPlayer CVS on Sat, 24 Apr 2004 12:33:22 +0200 (CEST). This fix is included in MPlayer 1.0pre4. Users of affected MPlayer versions should upgrade to MPlayer 1.0pre4 or later. 
 xine-lib fix was checked into CVS on Fri, Apr 23 21:59:04 2004 UTC. This fix is included in xine-lib 1-rc4. Users of affected xine-lib versions should upgrade to xine-lib 1-rc4 or later. If this upgrade is not feasible for some reason, the vulnerable code can be disabled by removing xine's RTSP input plugin, which is located at $(xine-config --plugindir)/xineplug_inp_rtsp.so). If installed with default paths, that is: /usr/local/lib/xine/plugins/1.0.0/xineplug_inp_rtsp.so This workaround disables RTSP streaming. 
 
Affected versions: 
 MPlayer 1.0pre1-pre3try2 
 xine-lib 1-beta1 to 1-rc3c 
 
Unaffected versions: 
 MPlayer 0.92.1 and below 
 MPlayer 1.0pre4 and above 
 MPlayer CVS HEAD 
 
 xine-lib 1-beta0 and below 
 xine-lib 1-rc4 and above 
 xine-lib CVS HEAD

Xine-lib version bumped to 1_rc4, 
KEYWORDS="~x86 ~ppc -hppa ~sparc ~amd64 -ia64 ~alpha"

Arch folks, please test and mark stable.

Gave it a thrashing, seems solid as ever... stable on x86.

mplayer-1.0_pre4.ebuild is in Portage, stable on x86, other archs please test
this one also.

Created an attachment (id=30367) [details]
Patch for deprecated CFLAGS -mcpu with gcc 3.4

This is patch resolve problem compiled package with gcc 3.4 for change -mcpu
with -mtune...

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

This is clearly the wrong place to post patches for gcc-3.4. 
1) gcc-3.4 is not supported yet thus why it's package masked.
2) This is a security bug not a porting bug.

There is a metabug that blocks gcc-3.4, I appologize for not having the # but a
search should get you.. please file a new bug for your patch and ideally make
it block the metabug. Thanks.

Ok, open new bug and submitted patch

I get the following errors with rc4 on amd64:

/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s: Assembler messages:
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:572: Error: Incorrect register `%rsi' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:600: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:623: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:642: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:661: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:681: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:706: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:727: Error: Incorrect register `%r8' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:763: Error: Incorrect register `%rsi' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:768: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:1885: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:1900: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:1915: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:1960: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:1969: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:1990: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:2287: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:2301: Error: Incorrect register `%rax' used with `l' suffix
/var/tmp/portage/xine-lib-1_rc4/temp/ccJyN0Gh.s:2314: Error: Incorrect register `%rax' used with `l' suffix
make[3]: *** [layer12.lo] Error 1
make[3]: Leaving directory `/var/tmp/portage/xine-lib-1_rc4/work/xine-lib-1-rc4/src/libmad'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/xine-lib-1_rc4/work/xine-lib-1-rc4/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/xine-lib-1_rc4/work/xine-lib-1-rc4'
make: *** [all] Error 2

Created an attachment (id=30401) [details]
emerge info on amd64

xine-lib and mplayer marked stable on alpha.

Experiencing some problems with testing mplayer against a rtsp stream on sparc,
player crashes.  Not quite sure yet.  Additionally xine-lib had some brokenness
for sparc64 in 1.0-pre4 and am working on fixing that as well.  Just wanted to
let you know it's being worked on in case it takes a day or so.

Why mark mplayer pre4 as stable on x86?
According to mplayerhq 0.92.1 and below are unaffected, and since the last stable previous to pre4 was 0.92 then I can't see the reason. pre4 has some other various bugs I experience (problems using soundcontrol, sometimes fullscreen-mode become missplaced) and I think those makes it unsmart to mark pre4 as stable because of a bug 0.92 does not have.

In looking over some of the mplayer documentation, it looks like unless you
have had the live useflag enabled, this problem doesn't effect you.  It was
just recently added to IUSE though it has been in the ebuilds for some time. 
One thing that was unclear to me (and I hope the media-video herd can clear
this up, hence the CC) is what REAL protocols work over rtp:// and rstp:// ? 
For some arches (like sparc) not all of the REAL codecs are supported since
there are not library hooks for us.  This could possibly mean that the security
bug is only valid for some arches.

mplayer seems to have a genuine bug when playing rstp streams on sparc.  I've
got no problems marking it stable if that's what we want to do.

As for xine-lib, it's having libtool problems where it'll drop the so from a
shared library, so libxine.so.1.8.1 is getting turned into libxine.1.8.1.  I
really have no clue on libtool stuff, and it doesn't seem to happen on my x86
box, so if anyone has any suggestions or could lend a hand, that'd be great!

Re mplayer 1_rc4 bump to stable, perhaps I was overagressive, but I've been
using mplayer
1_rc3 out of ~x86 for a long time now with no problems.. feel free to discuss
pros/cons...

Re AMD64 building, jhuebel, you're the amd64 man.. if you cant fix it, no one
can! Or something like that, I cant offer any advice there.

As for libtool issues on sparc but not x86? I dont know anything about either
beast, do we have any libtool gurus besides Az? Maybe SpanKY.

The stable bump for x86 was not needed for the GLSA, but if it's stable, why
not :)

Given the stable/unstable versions in history, we now need :
media-video/mplayer-1.0_pre4-r1 : x86 ppc ~sparc ~mips ~alpha ~hppa amd64 ~ia64
(and we currently have : KEYWORDS="~x86 ~ppc alpha ~amd64 -ia64 -hppa ~sparc")
media-libs/xine-lib-1_rc4 : x86 ppc sparc alpha hppa amd64 ia64
(and we currently have : KEYWORDS="x86 ~ppc -hppa ~sparc -amd64 -ia64 alpha")

So we still miss keywording or stable from : x86 ppc sparc hppa amd64 ia64 mips
Adding missing arches. tseng, can you mark mplayer-1.0_pre4-r1 stable on x86 ?

If mplayer cannot make it to stable amd64, we'll probably have to mask it...
-K

Still waiting for

mplayer-1.0_pre4-r1 : stable on x86, ppc, sparc
mplayer-1.0_pre4-r1 : ~keyworded on mips hppa ia64
xine-lib-1_rc4 : stable on ppc sparc amd64 hppa ia64

arches that cannot be stable (like xine-lib amd64) will probably be security.masked.

xine-lib is now stable on sparc.

even though xine-ui depends on xine-lib, it'd be nice to see a fairly recent
version of xine-ui in the tree (i'll even test it) it's xine-0.99.1 (as of
04/17/04)

please forgive my last post, i didn't see 48324

Problems I have explored with pre4 is for exampel:

Problems "remebering" subtitles: the only "secure" way (at least for me) to have mplayer accept subtitle-files is to load them with the appropriate button in the gui, else they most of the time don't like me. Drag and drop: forget it. skipping inside the file also makes mplayer sometimes for me forgot that it had a subtitle loaded.

Problems going to fullscreen: Sometimes (actually quite a lot of times) the upper left corne of where the videowindow had its edge also set the mark for where the fullscreen will hav it's upper left edge leaving me with a fullscreenmode just partially covering the desktop not showing the fully picture becouse parts of the for fullscreen upscaled picture got placed outside the screen and the only thing helping is restart mplayer hoping for it to work the next time I start it. 

This with the vx-driver. The other drivers I had other problems with finally making me merge 0.92 again.

This is why I think pre4 not should be marked stable.
It is just not yet a stable product upstream and since the 0.92.1 and below is not affected by this security-bug disscussed here there is no point forcing pre4 to stable.

I've had a couple of issues with 1.0_pre4 of mplayer. I also recommend that
0.92 be marked as the stable version again. Anybody else care to vote? ;-) 

As a reply to kurt's email on -dev, SPARC has stabilized everything that was
needed for this bug.  The 0.92-r1 ebuild is not prone to this vulnerability and
the version of xine-lib needed was stabilized.  I'm removing sparc as we have
done our part.  If for some reason we decide to mask pre 1 releases, please
notify sparc before doing so.

Jason : you're right, my mistake.
So we're still waiting for :

>=mplayer-1.0_pre4 : stable on amd64, ~keyworded on mips hppa ia64
>=xine-lib-1_rc4 : stable on ppc amd64 hppa ia64

removing x86 from cc: as they are ready too.

Still missing :

>=mplayer-1.0_pre4 : stable on ppc amd64, ~keyworded on mips hppa ia64
>=xine-lib-1_rc4 : stable on ppc hppa ia64

AMD64's all set.

ppc is all done :)

Thanks everyone, this is GLSA-ready

GLSA 200405-24