Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 49387 - media-video/mplayer, media-libs/xine-lib: multiple vulnerabilities in RTSP client
Summary: media-video/mplayer, media-libs/xine-lib: multiple vulnerabilities in RTSP cl...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: GLSA Errors (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Security
URL: http://www.mplayerhq.hu/homepage/desi...
Whiteboard:
Keywords:
: 49385 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-29 08:28 UTC by fbusse
Modified: 2004-11-10 12:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch for deprecated CFLAGS -mcpu with gcc 3.4 (configure.gcc3.4.patch,3.41 KB, patch)
2004-04-29 18:32 UTC, ares
Details | Diff
emerge info on amd64 (emerge-info.txt,1.40 KB, text/plain)
2004-04-30 11:52 UTC, Jason Huebel (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fbusse 2004-04-29 08:28:56 UTC
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
Comment 1 Brandon Hale (RETIRED) gentoo-dev 2004-04-29 14:42:01 UTC
Xine-lib version bumped to 1_rc4, 
KEYWORDS="~x86 ~ppc -hppa ~sparc ~amd64 -ia64 ~alpha"

Arch folks, please test and mark stable.
Comment 2 Brandon Hale (RETIRED) gentoo-dev 2004-04-29 14:57:01 UTC
Gave it a thrashing, seems solid as ever... stable on x86.
Comment 3 Brandon Hale (RETIRED) gentoo-dev 2004-04-29 16:04:45 UTC
mplayer-1.0_pre4.ebuild is in Portage, stable on x86, other archs please test this one also.
Comment 4 ares 2004-04-29 18:32:36 UTC
Created attachment 30367 [details, diff]
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...
Comment 5 Brandon Hale (RETIRED) gentoo-dev 2004-04-29 18:52:44 UTC
*** Bug 49385 has been marked as a duplicate of this bug. ***
Comment 6 solar (RETIRED) gentoo-dev 2004-04-29 19:27:06 UTC
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.
Comment 7 Brandon Hale (RETIRED) gentoo-dev 2004-04-29 20:01:16 UTC
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.
Comment 8 ares 2004-04-30 05:05:20 UTC
Ok, open new bug and submitted patch
Comment 9 Jason Huebel (RETIRED) gentoo-dev 2004-04-30 11:50:55 UTC
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
Comment 10 Jason Huebel (RETIRED) gentoo-dev 2004-04-30 11:52:54 UTC
Created attachment 30401 [details]
emerge info on amd64
Comment 11 Bryan Østergaard (RETIRED) gentoo-dev 2004-04-30 15:00:20 UTC
xine-lib and mplayer marked stable on alpha.
Comment 12 Jason Wever (RETIRED) gentoo-dev 2004-04-30 16:45:55 UTC
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.
Comment 13 Xake 2004-05-01 08:34:07 UTC
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.
Comment 14 Jason Wever (RETIRED) gentoo-dev 2004-05-01 10:33:02 UTC
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.
Comment 15 Jason Wever (RETIRED) gentoo-dev 2004-05-02 11:06:11 UTC
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!
Comment 16 Brandon Hale (RETIRED) gentoo-dev 2004-05-02 13:33:34 UTC
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.
Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2004-05-04 07:03:07 UTC
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
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2004-05-06 13:40:31 UTC
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.
Comment 19 Jason Wever (RETIRED) gentoo-dev 2004-05-09 18:17:15 UTC
xine-lib is now stable on sparc.
Comment 20 Allen Parker 2004-05-10 12:23:42 UTC
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)
Comment 21 Allen Parker 2004-05-10 12:36:00 UTC
please forgive my last post, i didn't see 48324
Comment 22 Xake 2004-05-10 15:48:02 UTC
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.
Comment 23 Joel Martin (RETIRED) gentoo-dev 2004-05-10 19:55:08 UTC
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? ;-) 
Comment 24 Jason Wever (RETIRED) gentoo-dev 2004-05-23 13:34:07 UTC
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.
Comment 25 Thierry Carrez (RETIRED) gentoo-dev 2004-05-24 01:06:57 UTC
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.
Comment 26 Thierry Carrez (RETIRED) gentoo-dev 2004-05-27 05:48:09 UTC
Still missing :

>=mplayer-1.0_pre4 : stable on ppc amd64, ~keyworded on mips hppa ia64
>=xine-lib-1_rc4 : stable on ppc hppa ia64
Comment 27 Jon Portnoy (RETIRED) gentoo-dev 2004-05-27 12:23:08 UTC
AMD64's all set.
Comment 28 Daniel Ostrow (RETIRED) gentoo-dev 2004-05-27 21:35:07 UTC
ppc is all done :)
Comment 29 Thierry Carrez (RETIRED) gentoo-dev 2004-05-28 01:42:55 UTC
Thanks everyone, this is GLSA-ready
Comment 30 Thierry Carrez (RETIRED) gentoo-dev 2004-05-28 10:26:49 UTC
GLSA 200405-24