|Summary:||media-libs/xine-lib : filesystem write vulnerability XSA-2004-1|
|Component:||GLSA Errors||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||45448, 48324|
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 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