xine security announcement
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.
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.
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.
All 1-alpha releases.
All 1-beta releases.
All 1-rc releases up to and including 1-rc3a.
All 0.9 releases or older.
1-rc3b or newer.
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/
Created attachment 29470 [details, diff]
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.
marked stable on amd64...
Marked stable on Alpha.
Stable on sparc.
Bump: x86, ppc : please test and mark stable (if stable :) )
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.
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 :)
I marked it stable on ppc. It works on my ~ppc box and it is better than to mask it.
Stable on x86.
GLSA-ready -- draft written