Apple Quicktime FLIC File Heap Overflow (Technical Details)
18 Sep. 2006
Summary
There is a flaw in QuickTime FLIC parser, the flaw is located within the "COLOR_64 chunk" Quicktime parser. Since proper checking is not performed, a large amount of heap can be overwritten with controlled values. This flaw could lead to a remote code execution,if an attacker tricks the victim to visit a malicious webpage with a specially crafted .fli animation embedded.
Vulnerable Systems:
* Apple Quicktime version 7.1 and prior
Immune Systems:
* Apple Quicktime version 7.1.3
FLC/FLI format overview:
FLIC files are structured in a hierarchy of chunks. A chunk contains a fixed part and a variable part. Every chunk starts with a 6-byte header, that contains the size (four bytes) and the type (two bytes) for the chunk
FRAME CHUNK HEADER
typedef struct {
DWORD size; /* Size of the chunk, including subchunks */
WORD type; /* Chunk type: 0xF1FA */
WORD chunks; /* Number of subchunks */
WORD delay; /* Delay in milliseconds */
short reserved; /* Always zero */
ushort width; /* Frame width override (if non-zero) */
ushort height; /* Frame height override (if non-zero) */
} FRAME_TYPE;
Chunk type: 0xB COLOR_64 64-level colour palette
The data in the COLOR_64 chunk is organized in packets. The first word next to the chunk header is the number of packets of the chunk. Each packet is structured in a 1-byte skip count, a 1-byte copy count and a series of 3-byte RGB values (the "copy count" gives us the number of RGB triplets). If the copy count is zero, there are 256 RGB triplets in the packet.
So, the flaw is that QuickTime allocates 0x100*sizeof(DWORD) in order to copy just one palette. However, the parameters are directly copied from FLC/FLI/CEL file without validate them. Thus, we can overwrite a large amount of heap memory using controlled DWORD values. The total amount of heap memory we could overwrite, is the result of the following formula: Max = MaxNumberofSubChunks * ( sizeof(DWORD) * sizeof(PALETTE) )
Max = FFFFh * (4* 100h);
Max = 0x3FFFC00; a lot...
In addition, we could overwrite just certain blocks on the heap, thus controlling the memory corrupted. How? Using the byte Skip field ,remember: .text:679FE50D lea esi, [esi+edx*4] ; skip the bytes +align
The amount of bytes overwritten each time also could be controlled using CopyCount Field
The asm code previously explained would appear in C as follows:
[...]
ptr_heap=(LPVOID)malloc(0x100*sizeof(DWORD)); // chungootronics from the outer space
[...]
for (i = 0; i < subchunks; i++) {
if(buf[stream++] != 0) ptr_heap += buf[stream]; // colors to skip (distance )
CopyCount = buf[stream++]; // entries to change
if (CopyCount == 0) Copycount = 0x100; //(entire palette)
for (j = 0; j < CopyCount; j++)
{
...HEAP OVERFLOW
};
}
