FLAC音频格式被发现大量安全漏洞

最新消息：eEye Digital Security 找出了多达14个FLAC文件的漏洞,这些漏洞同时影响Windows, Mac OS, Linux, Unix, BSD, Solaris,甚至可以破坏支持播放FLAC的硬件!
安全人员指出,FLAC中的缺陷主要作用于一些开源音频编码库,当播放一些经过特别设计的FLAC音频时可能会导致相应的媒体播放器出现问题,eEye已经提醒US-CERT关注这一严重问题.

以下摘自英文原文： 本文来自注册机之家

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.

看完这篇新闻有何感觉