Talos Vulnerability Report


Apple Quicktime mdat Corruption Denial of Service Vulnerability

Aug 13, 2015


There is a denial of service vulnerability in Apple Quicktime. An attacker who can control the content of the mdat section of a .mov file can cause an out-of-bounds read. Since the allocation only contains data already from the file, the impact is limited to denial of service.

Tested Versions

Apple Quicktime 7.7.5 - Windows 7 32-bit Vulnerable
Apple Quicktime 7.7.6 - Windows 7 32-bit Vulnerable

Product URLs



The function QuickTimeAuthoring!0x63f00 operates on data from the mdat atom in a loop.

At various points, there is a buffer sanity check to ensure the current position within the data buffer has not exceeded the end of the buffer, after which 4 bytes are read from the current position.

.text:69414704                 cmp     esi, [esp+44h+arg_0] <------- check that esi < end of memory block
.text:69414708                 jnb     loc_6B4A4867
.text:6941470E loc_6B4A470E:
.text:6941470E                 mov     edx, [esi]      <--------- Read of 4 bytes
.text:69414710                 mov     ecx, edx

and here:

.text:694147E7                 cmp     esi, [esp+44h+arg_0] ; Check ptr not past end
.text:694147EB                 jnb     short loc_69414867
.text:694147ED loc_694147ED:
.text:694147ED                 mov     edx, [esi]      <---------- Read of 4 bytes
.text:694147EF                 add     eax, [esp+44h+var_30]

The function iterates through a large section of memory reading in four bytes at a time. If the 4 bytes read in matches a specific control code, it alters the behavior of the function, causing it to advance through the data by either 1, 3, or 4 bytes.

If the function reads in a control code that throws the function out of sync with the alignment of the object, an out-of-bounds read may occur.

For example, if the data buffer is 0x100 bytes, and the function parses the data along 4-byte increments, hits a control code (0x80000000) that skips the data by 1, then continues to parse 4 byte increments till the end of the memory buffer, at some point the function gets into a situation where 0xfd bytes have been read. The function checks to ensure cursor < end of buffer, but because we're out of alignment, the check passes (0xfd < 0x100). Another 4 bytes are then read, resulting in a read 1 byte off the end of the buffer.

No check is there to ensure current location + number of bytes to read < end of buffer before reading.

Crash Information

eax=07ff0ef0 ebx=00300000 ecx=003080ff edx=00003000 esi=10702ffd edi=000009b2
eip=690e47ed esp=0043ba38 ebp=00300000 iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210297
690e47ed 8b16            mov     edx,dword ptr [esi]  ds:0023:10702ffd=????????

0043ba74 6a084251 690de7f0 10702ffe c0c0c000 QuickTimeAuthoring!RPZA_CDComponentDispatch+0x595d
0043badc 6a083491 000003f0 1e276fd0 0043bb50 QuickTime!CallComponentFunctionWithStorage+0xd41
0043bb54 6a791841 008200d5 1e5adf34 00000000 QuickTime!CallComponent+0x51
0043bb74 6a78fff9 1e27ce90 1e5adf10 0043bf6c QuickTime!Base_CDComponentDispatch+0x2391
0043bbc8 6a79033a 1e27ce01 6a790dcb 00000000 QuickTime!Base_CDComponentDispatch+0xb49
0043bbd0 6a790dcb 00000000 1e27cee8 0043bd78 QuickTime!Base_CDComponentDispatch+0xe8a
0043bc0c 6a083545 1e27ce90 0043bf6c 6a78f4ed QuickTime!Base_CDComponentDispatch+0x191b
0043bc18 6a78f4ed 1e27ce90 0043bd78 6a790340 QuickTime!CallComponentFunctionWithStorage+0x35
0043bf6c 2056cc4e 10702648 000009b2 00000003 QuickTime!Base_CDComponentDispatch+0x3d
0043bf70 10702648 000009b2 00000003 00000000 0x2056cc4e
0043bf74 00000000 00000003 00000000 00000078 0x10702648


Discovered by Ryan Pentney and Richard Johnson of Cisco Talos