Bug 48107 – media-libs/xine-lib : filesystem write vulnerability XSA-2004-1

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description fbusse 2004-04-16 22:31:28 UTC]

xine security announcement
==========================

Announcement-ID: XSA-2004-1

Summary:
By opening a malicious MRL in any xine-lib based media player, an attacker can 
write arbitrary content to an arbitrary file, only restricted by the 
permissions of the user running the application.

Description:
MRLs (media resource locator) are a subset of URIs used by the xine-lib 
library to describe the location of the content to play. MRLs also offer the 
feature of providing xine configuration options, which will be activated 
right before the addressed content is played. But some of xine's 
configuration options specify files that will be written to during playback. 
One example of such an option is "audio.sun_audio_device", which specifies 
the audio device on SUN machines. The decoded PCM samples of the audio stream 
will be written to this file. By having a user open a MRL like 
"http://myserver/mybashrc#audio.sun_audio_device:.bashrc" in xine, which 
changes the value of the "audio.sun_audio_device" option and plays a 
specially crafted audio stream, an attacker could fill any file the user has 
access to with arbitrary content. Other configuration options that allow such 
an attack exist (we also found "dxr3.devicename"), so the vulnerability is 
not limited to SUN machines.

Severity:
Expoits have not been seen in the public and not all xine setups use the 
vulnerable configuration options. But at least xine users on SUN machines and 
users of a DXR3 or Hollywood+ MPEG decoder card are vulnerable. Other such 
problematic configuration options might have slipped through the review or 
might be provided by xine plugins outside the main xine distribution, leaving 
other users vulnerable as well. Given the wide range of possible harm, we 
consider this problem to be highly critical.

Affected versions:
All 1-alpha releases.
All 1-beta releases.
All 1-rc releases up to and including 1-rc3a.

Unaffected versions:
All 0.9 releases or older.
1-rc3b or newer.

Solution:
Changes to xine configuration options via MRL are now disabled by default.
The attached patch to xine-lib fixes the problem but should only be used by 
distributors who do not want to upgrade. Otherwise, we strongly advise 
everyone to upgrade to the 1-rc3c release of xine-lib.

For further information and in case of questions, please contact the xine 
team. Our website is http://xinehq.de/

Michael Roitzsch

[Comment 1 fbusse 2004-04-16 22:32:06 UTC]

Created attachment 29470 [details, diff]
xine-lib patch

[Comment 2 Thierry Carrez (RETIRED) 2004-04-17 07:51:19 UTC]

xine-lib-1_rc3-r3.ebuild is the 1-rc3c version, so it includes the fix.

We just need it available on all arch and stable before issuing a global xine-ui / xine-lib GLSA.

[Comment 3 Travis Tilley (RETIRED) 2004-04-17 12:09:02 UTC]

marked stable on amd64...

[Comment 4 Bryan Østergaard (RETIRED) 2004-04-17 14:23:21 UTC]

Marked stable on Alpha.

[Comment 5 Jason Wever (RETIRED) 2004-04-17 21:03:36 UTC]

Stable on sparc.

[Comment 6 Thierry Carrez (RETIRED) 2004-04-21 11:43:50 UTC]

Bump: x86, ppc : please test and mark stable (if stable :) )
-K

[Comment 7 Lars Weiler (RETIRED) 2004-04-21 17:01:01 UTC]

Sorry, too few testers with stable machines on ppc.

But this version of xine (and xine-lib) seems to be the first since a long time, that works again on ppc.  But sometimes I have issues with the correct colours and sometimes xine just exists with a memory error.

I propose for not updating (or mask it comletely for ppc).  But my system could also be unstable at some parts.  Hopefully somebody else will also test on ppc.

PS: Testen on a G3 which has no Altivec.

[Comment 8 Thierry Carrez (RETIRED) 2004-04-22 00:37:49 UTC]

Lars:

For ppc we have for the moment xine-ui-0.9.13-r1 and xine-lib-1_rc3-r1 stable, which are both vulnerable. So you have two choices :

1- xine-ui-0.9.23-r2 and xine-lib-1_rc3-r3 work the same / better than the old stable, in which case we should mark them stable

2- they work worse, in which case we should package.mask the two packages since we cannot let vulnerable or unstable packages there.

Your call :)

[Comment 9 David Holm (RETIRED) 2004-04-26 01:37:12 UTC]

I marked it stable on ppc. It works on my ~ppc box and it is better than to mask it.

[Comment 10 Brandon Hale (RETIRED) 2004-04-26 07:48:31 UTC]

Stable on x86.

[Comment 11 Thierry Carrez (RETIRED) 2004-04-26 09:43:05 UTC]

GLSA-ready -- draft written

[Comment 12 Joshua J. Berry (CondorDes) (RETIRED) 2004-04-26 22:49:31 UTC]

GLSA 200404-20.