EEYE: Multiple Vulnerabilities In .FLAC File Format and Various Media Applications Nov 15 2007 07:59PM
eEye Advisories (eEyeAdvisories eeye com)
Multiple Vulnerabilities In .FLAC File Format and Various Media

Release Date:
November 15, 2007

Date Reported:
September 28, 2007 (Vendor Reporting Coordination Began With US-CERT)

High (Remote Code Execution)

Multiple Vendors

Systems Affected:
Applications with FLAC Support

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:

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

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.

Blink - Unified Client Security has proactively protected from these
vulnerabilities since their discovery.
Retina - Network Security Scanner has been updated to identify these

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.

Greg Linares

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:
Blink - Unified Client Security Personal - Free For Home Use:
Blink - Unified Client Security Professional - Free Trial:

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.

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.

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus