CVE-2015-3792
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.
Apple Quicktime 7.7.5 - Windows 7 32-bit Vulnerable
Apple Quicktime 7.7.6 - Windows 7 32-bit Vulnerable
https://www.apple.com/quicktime/
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
.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
.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.
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
QuickTimeAuthoring!RPZA_CDComponentDispatch+0x595d:
690e47ed 8b16 mov edx,dword ptr [esi] ds:0023:10702ffd=????????
STACK_TEXT:
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
Ryan Pentney and Richard Johnson of Cisco Talos