喜爱听无损音乐的朋友们一定要注意咯,eEye Digital Security 找出了多达14个FLAC文件的漏洞,这些漏洞同时影响Windows, Mac OS, Linux, Unix, BSD, Solaris,甚至可以破坏支持播放FLAC的硬件!
安全人员指出,FLAC中的缺陷主要作用于一些开源音频编码库,当播放一些经过特别设计的FLAC音频时可能会导致相应的媒体播放器出现问题,eEye已经提醒US-CERT关注这一严重问题.
http://research.eeye.com/html/advisories/published/AD20071115.html
Multiple Vulnerabilities In .FLAC File Format and Various Media Applications
Release Date:
November 15, 2007
Date Reported:
September 28, 2007
Patch Development Time (In Days):
 |
|
|
|
| 48 |
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抯 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抯 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抯 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.