Advisory from firstname.lastname@example.org:
Date: 15 Dec 2004 08:18:11 -0000
From: "D. J. Bernstein" <email@example.com>
Subject: [remote] [control] MPlayer 1.0pre5 get_header overflows data buffer
To: firstname.lastname@example.org, email@example.com
X-HELOcheck: OK: FQDN
Mailing-List: contact firstname.lastname@example.org; run by ezmlm
Mail-Followup-To: email@example.com, firstname.lastname@example.org
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 MPlayer. I'm
publishing this notice, but all the discovery credits should be assigned
You are at risk if you use MPlayer to play an ASF video stream from the
web (or from any other source that could be controlled by an attacker).
Whoever provides that stream then has complete control over your
account: he can read and modify your files, watch the programs you're
Proof of concept: On an x86 computer running FreeBSD 4.10 with ucspi-tcp
bunzip2 < MPlayer-1.0pre5.tar.bz2 | tar -xf -
to download and compile the MPlayer program, version 1.0pre5 (current).
Then save the file 17-s.c attached to this message, and type
gcc -o 17-s 17-s.c
tcpserver 0 1755 ./17-s &
with the unauthorized result that a file named x is removed from the
current directory. (I tested this with a 538-byte environment, as
reported by printenv | wc -c.)
Here's the bug: In asf_mmst_streaming.c, get_header() uses get_data()
to copy an input-specified amount of data into a 102400-byte data
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Created attachment 46027 [details]
17-s.c from the advisory
chriswhite, pls verify and advise
MPlayer 1.0pre5try2 is out :
media-video: please bump
Ugh, lovely... Unfortunately, I won't be able to get to this until tommorow (finals bleh :( ). But after my final tommorow, I'll be on this and bumping asanhcph (As soon as non humans can possibly handle).
Mkay, bumped as requested. New version to use is pre5-r5. Let's see, keywords targets are:
x86 ppc alpha amd64 hppa sparc ppc64
and ppc64, pre5-r4 was marked stable with no changelog entry.. what's up with that?
x86 was taken careof by yours truly. More fun :P. Also removing myself from CC as I already get security and media-video spam as is :P.
Stable on amd64
Done on ppc.
Stable on sparc
Stable on alpha.
stable on ppc64.
sorry about the missing changelog entry. I added it manualy.
ia64, mips: you should mark _pre5-r5 "~" so that you benefit from GLSA.