[NEWS] Multiple Vulnerabilities in .FLAC File Format and Various Media Applications



The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Multiple Vulnerabilities in .FLAC File Format and Various Media
Applications
------------------------------------------------------------------------


SUMMARY

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

DETAILS

Vulnerable Systems:
* libFLAC version 1.2 and prior

Immune Systems:
* libFLAC version 1.2.1

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


ADDITIONAL INFORMATION

The information has been provided by eEye Digital Security.
The original article can be found at:
<http://www.kb.cert.org/vuls/id/544656>
http://www.kb.cert.org/vuls/id/544656



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages