Bugzilla Bug 74475

Advisory from securesoftware@list.cr.yp.to:

Date: 15 Dec 2004 08:19:21 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: [remote] [control] xine-lib open_aiff_file overflows buffer
To: securesoftware@list.cr.yp.to, xine-user@lists.sourceforge.net
X-HELOcheck: OK: FQDN
Mailing-List: contact securesoftware-help@list.cr.yp.to; run by ezmlm
Mail-Followup-To: securesoftware@list.cr.yp.to,
        xine-user@lists.sourceforge.net
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.

[-- Attachment #1 [details] --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.4K --]

Ariel Berkman, a student in my Fall 2004 UNIX Security Holes course, has
discovered a remotely exploitable security hole in xine-lib. I'm
publishing this notice, but all the discovery credits should be assigned
to Berkman.

You are at risk if you take a file from the web (or email or any other
source that could be controlled by an attacker) and feed that file
through xine or any other xine-lib frontend. Whoever provides that file
then has complete control over your account: he can read and modify your
files, watch the programs you're running, etc.

Proof of concept: On an x86 computer running FreeBSD 4.10, as root, type

   cd /usr/ports/multimedia/xine
   make install

to download and compile the xine-lib library, version 1-rc5, and the
xine program. (Version 1-rc5 has other problems but is the latest ports
version. Version 1-rc7 fixes several bugs but does not fix the bug used
here.) Then save the file 20.avi attached to this message, and type

   xine 20.avi

with the unauthorized result that a file named EXPLOITED is created in
the current directory. (I tested this with a 577-byte environment, as
reported by printenv | wc -c; beware that 20.avi is sensitive to the
environment size.)

Here's the bug: In demux_aiff.c, open_aiff_file() reads an
input-specified amount of data into a 100-byte buffer[] array.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Created an attachment (id=46028) [details]
20.avi from the advisory

xine-lib-1_rc8 is out :
https://sourceforge.net/project/shownotes.php?group_id=9655&release_id=290099

media-video: please bump.

I'll just copy marking from the last ebuild :P:

alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86

are the intended keywords (I'm cc-ing mips because they marked _rc6 but not anything else above it, so mark it ~mips for your benifit).

x86 is already done.  Ensured compilation under ~x86 and hardened gcc as well (so I know that the hardened patches would work).  That's all for today :P.

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

stable on ppc64

This appears to be having libtool issues similar to earlier versions of
xine-lib on SPARC where the .so in libxine.so.1 gets dropped (so the filename
is resulting in libxine.1).  I'll look into it more tonight after work unless
someone beats me to it.

======================================================
Candidate: CAN-2004-1300
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1300
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/xine-lib.txt

Buffer overflow in the open_aiff_file function in demux_aiff.c for
xine-lib (libxine) 1-rc7 allows remote attackers to execute arbitrary
code via a crafted AIFF file.
======================================================

Stable on alpha.

Did manage to get xine-lib-1_rc8 to build correctly for sparc, but xine-ui
always generates bus errors on startup.  strace reveals nothing of use and gdb
cores when trying to debug it.

How hard would this fix be to backport to 1_rc7?

a user has got a problem with -fPIC on amd64 (bug #75247), but i can't
reproduce it. perhaps anybody else?

Hmmm in fact xine-lib 1_rc8 fixes :

CAN-2004-1187
Multiple Vendor Xine 0.99.2 PNM Handler PNA_TAG Heap Overflow Vulnerability
http://www.idefense.com/application/poi/display?id=176&type=vulnerabilities

CAN-2004-1188
Multiple Vendor Xine 0.99.2 PNM Handler Negative Read Length Overflow Vulnerability
http://www.idefense.com/application/poi/display?id=177&type=vulnerabilities

But it doesn't fix the DJB one. For that you need the following patch :
http://cvs.sourceforge.net/viewcvs.py/xine/xine-lib/src/demuxers/demux_aiff.c?r1=1.39&r2=1.40

media-video team, please bump ebuild with patch. Maybe also see if a backport of all those patches for 1_rc7 looks possible and/or see with sparc what can be done about xine-ui.

Removing arches for now. Sorry for the interference.

Created an attachment (id=46631) [details]
CAN-2004-1300.patch

Patch taken from xine CVS

patch applied and ebuild bumped to -r1

intended KEYWORDS are:

alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86

x86 is done.

*pause*

somehow something weird happened with cvs and the djb patch, so pardon while I fix all that.  I'm also fixing an apparent error that some other people are having with the latest xorg-x11 and x86/amd64.  I'll update this in a bit.

*unpause* fixed stuff.

stable on ppc64

stable on ppc

Stable on alpha.

amd64 stable

Weeve is working on some issues arrising in xine-lib, so that's what's taking
time.

Sorry for the delay here.  Still looking into these issues.  Unstable sparc is
running into problems with libtool mismatches between what is installed on the
system and what xine-lib is trying to use from its own source.  This will need
to be corrected as well.  My preference would be to have the package maintainer
fix this issue as it keeps the version with the fix from being built and
happens on more than just SPARC.

I will still keep working on trying to diagnose the issues with xine-lib at
runtime.

weeve: cvs update for the libtool stuff

I'm having trouble with xine-lib rc8-r1 on sparc being unresponsive (xine-ui hangs on startup).  I'll try 1.0 with the new xine-ui as well...

arm/hppa/ia64 stable

What's the status on sparc ? Does xine-lib still fail with eradicator's cvs
update  ? Does 1.0 solve those issues ?

Stable on mips.

koon: sparc is still unable to mark rc8 or greater stable.  Chriswhite, can you
backport the security fix to rc6?

weeve: I bumped to xine-lib-1_rc6-r1.ebuild with the attached patch.  My sparc
is a bit occupied at the moment, can you test it out when you get the chance...
otherwise I'll test it in the morning... worked on my amd64, and since rc6
worked for sparc before, I'm fairly confident it'll work...

Weeve is away until jan 7.
I gave rc6-r1 a spin here and it seems to work with mpeg, but not avi (tried the infamous dancemonkeyboy.avi) with one of those horrible bus errors.
1.0 final doesn't work with anything.

Gustavo: please confirm that it's a regression (i.e. that dancemonkeyboy.avi
worked with the previous stable). If it's not (=known bug) then mark stable
anyway.

it's not a regression (not here atleast).  marked stable on sparc.  It looks
like a problem with ffmpeg, not xine-lib...

Could you please remove affected versions from portage (at least the "rc7" and
"rc8") ?

GLSA 200501-07