Advisory from email@example.com:
Date: 15 Dec 2004 08:19:21 -0000
From: "D. J. Bernstein" <firstname.lastname@example.org>
Subject: [remote] [control] xine-lib open_aiff_file overflows buffer
To: email@example.com, firstname.lastname@example.org
X-HELOcheck: OK: FQDN
Mailing-List: contact email@example.com; run by ezmlm
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
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
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
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
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 attachment 46028 [details]
20.avi from the advisory
xine-lib-1_rc8 is out :
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.
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 :
Multiple Vendor Xine 0.99.2 PNM Handler PNA_TAG Heap Overflow Vulnerability
Multiple Vendor Xine 0.99.2 PNM Handler Negative Read Length Overflow Vulnerability
But it doesn't fix the DJB one. For that you need the following patch :
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 attachment 46631 [details, diff]
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.
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 ppc
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...
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") ?