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 attachment 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 attachment 46631 [details, diff] 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 ppc
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
