Multiple Vulnerabilities In .FLAC File Format and Various Media Applications Release Date: November 15, 2007 Date Reported: September 28, 2007 (Vendor Reporting Coordination Began With US-CERT) Severity: High (Remote Code Execution) Vendor: Multiple Vendors Systems Affected: Applications with FLAC Support Overview: eEye Digital Security has discovered 14 vulnerabilities in the processing of FLAC (Free-Lossless Audio Codec) files affecting various applications. Processing a malicious FLAC file within a vulnerable application could result in the execution of arbitrary code at the privileges of the application or the current user (depending on OS). Technical Details: The vulnerabilities in the .FLAC format are due to improperly handling metadata values from malformed files. The file format is available here: http://flac.sourceforge.net/format.html. Vulnerability #1: Metadata Block Size Heap Overflow The first notable vulnerability is the Metadata Block Size Overflow vulnerability. Editing any Metadata Block Size value to a large value such as 0xFFFFFFFF may result in a heap based overflow in the decoding software. Whenever vulnerable software open or process a malformed FLAC file, they use the size fields for reference points to allocate memory (malloc) and write the contents of these files into those memory buffers. Setting these values to an overly large value, such as 0xFFFFFFFF, could cause an exploitable condition. Passing a size of 0xFFFFFFFF would cause a malloc(0) immediately followed by a buffer overflow on the read. This results in an exploitable heap overflow. Exploitation is dependent on the data allocation location, heap structure and error handlers of the affected software. After overwriting a large amount of memory and pointers with arbitrary data, code execution could then be redirected to the attacker's payload located inside the FLAC file. Vulnerability #2: VORBIS Comment String Size Field Heap Overflow The second vulnerability lies within the parsing of any VORBIS Comment String Size fields. Settings this fields to an overly large size, such as 0xFFFFFFF, could also result in another heap-based overflow allowing arbitrary code to execute in the content of the decoding program. Similar to the Metadata Block Size Overflow vulnerability above, exploitation depends on data allocation location, heap structure and error handlers of the affected application. Exploitation would be achieved by overwriting pointers in memory with arbitrary values stored inside the FLAC file or hard coded addresses in DLL files that directing code execution toward the attacker's payload. Vulnerability #3: VORBIS Comment String Size Length Stack Overflow This is due to predetermined buffer sizes in applications when handling data in the VORBIS Comment Metadata block. By inserting an overly long VORBIS Comment data string along with an large VORBIS Comment data string size value (such as 0x000061A8 followed by 25,050 A's), applications that do not properly apply boundary checks will result in a stack-based buffer overflow. This is due to most applications reading data until they encounter a NULL byte. Vulnerability #4: Picture MIME-Type Size Heap Overflow The Picture Metadata block allows the insertion of a MIME-Type for the embedded album art in a FLAC file. This field is vulnerable to a heap-based overflow when applications that support FLAC album art attempt to process an overly large MIME-TYPE Size field. Again arbitrary code execution depends on the location of the overwritten memory, the vulnerable programs exception handling, structure of the heap at the time of the overflow, and the ability to process Picture Data within FLAC files. Vulnerability #5: Picture MIME-Type Stack Overflow By using the same technique as the VORBIS Comment String Stack Overflow, by setting a large size value at roughly 5000 bytes (depending on the vulnerable application) and a large string value for the Picture MIME-Type a stack-based overflow can be reached. Exploitation depends on bounds-checking within the application in conjunction with the ability to process Picture Data within FLAC files. Vulnerability #6: Picture Dimension Size Heap Overflow By modifying the width and height values in the PICTURE Metadata block, a heap-based overflow could be achieved. When a vulnerable application that supports FLAC images attempts to render the excessively large image, the application allocates memory based on the dimension fields, which could be used to overwrite memory values and pointers with arbitrary values that could lead to code execution. Vulnerability #7: Picture Description Size Heap Overflow Overly large Description Size values such as 0xFFFFFFFF can lead to a heap based memory corruption and execute arbitrary code on vulnerable applications that support the Picture Metadata block. Successful exploitation depends on the location of the overwritten memory, the vulnerable programs exception handling, and structure of the heap at the time of the overflow. Vulnerability #8: Picture Description Length Stack Overflow Similar to the VORBIS Comment String Length Stack Overflow, this would be conducted in the same manner, by entering both an overly large Description Size value in conjunction with an excessively large Description String value. This could also lead to a stack based buffer overflow with the potential to overwrite any exception handlers depending on the vulnerable application. Vulnerability #9: Picture Data Length Heap Overflow By modifying the Picture Data Length field to an excessively large value, such as 0xFFFFFFFF, a heap based overflow can be achieved. When a vulnerable application that supports Picture Metadata blocks processes an album art image, it uses this field to determine the size in bytes of the embedded image file. This memory is allocated without bounds checking and could be used to overwrite memory and pointers with arbitrary values from inside the FLAC file. Vulnerability #10: Picture URL Stack Overflow Whenever a FLAC file's MIME-Type is set to "-->" this is a flag to indicate that the value for Data is not actually the contents of an image file but a URL to where the image file is located. By setting this value to an overly large string value, applications with FLAC image support could be vulnerable to a stack based buffer overflow that could allow arbitrary code execution. Vulnerability #11: Malformed Image/File Download Vulnerability Using the "-->" MIME-Type flag to signal a URL for a FLAC image file could allow the possibility of arbitrary file downloads if the application does not verify the file-type prior to downloading the file. This could also be combined with GDI+ or other picture rendering vulnerabilities to allow code execution depending on the application. This could also be applied to image files inserted into the FLAC file. Alternatively, this might be a vector to store malicious data, such as an attacker's payload. This could then be combined with another vulnerability to allow a more reliable exploit especially if the data retrieved by the vulnerable application is stored in a reliable memory address. Vulnerability #12: Padding Length Heap Overflow An overly large Padding length field value would set the basis for another heap overflow inside a vulnerable application. By setting this value to a large value such as 0xFFFFFFFF, a malformed FLAC file could cause a heap based corruption scenario when the memory for the Padding length is calculated without proper bounds checks. Vulnerability #13: Seektable Out-Of-Scope Double Free Condition By modifying the Seektable values with invalid data point references inside a malformed FLAC file, a Double Free (deallocation of a pointer not malloc'd) condition could be initiated. Furthermore the location of the freed pointer could be controlled by arbitrary values hosted inside the FLAC file. This could lead to an exploitable condition that could allow arbitrary code execution under the right circumstances. Vulnerability #14: Malformed Seektable Double Free Condition Setting multiple Seektable Data Offsets to large values such as 0x41414141 and then setting Seektable Points to cross reference each other can lead to multiple Double Free conditions (up to 12 in our tests) particularly on Mac OS. This is ideally achieved using multiple FLAC files with multiple malformed seektables. These conditions are not trivial to exploit but could lead to arbitrary code execution particularly since the deallocated pointers can be controlled by values from within the file, similar to the above condition. Protection: Blink - Unified Client Security has proactively protected from these vulnerabilities since their discovery. Retina - Network Security Scanner has been updated to identify these vulnerabilities. Vendor Status: libFLAC version 1.2.1 was released in September, 2007, fixing these vulnerabilities for most vulnerable applications. Unfortunately, many vendors that were using libFLAC within their media applications or using their own homegrown FLAC file parsers had not been informed that their FLAC file parser was vulnerable. Because of that, the release of this advisory was postponed until all vulnerable vendors were contacted in coordination with US-CERT. Credit: Greg Linares Greetings: the DiREctor, WDormann - thank you!, CI and his fav .jpg, Mr. BR and ITSix - you people are awesome, Casey aka 'The Puppetmaster', Pete the fish and his awesome owner, The Laughing Man, the unsung heroes JM and AC, Public Security Section 9, Pacman.exe, NormalBoy, JSoler, The 2008 Super Soeder Bros Convention Crashing team, SDR and I.D.L. - Nice job guys, and to JC - without you this wouldn't have been possible. eEye Research would also like to thank US-CERT for the assistance in vendor reporting considering the long list of vulnerable vendors. Related Links: Preview - Advanced Security Intelligence - http://www.eeye.com/preview Retina - Network Security Scanner - Free Trial: http://www.eeye.com/html/products/retina/download/index.html Blink - Unified Client Security Personal - Free For Home Use: http://www.eeye.com/html/products/blink/personal/download/index.html Blink - Unified Client Security Professional - Free Trial: http://www.eeye.com/html/products/blink/download/index.html Copyright (c) 1998-2007 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email alert (at) eEye (dot) com [email concealed] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.