Talos Vulnerability Report

Description

There is a denial of service vulnerability in Apple Quicktime. An attacker who can control the size of a samr atom in a .mov file can cause an undersized allocation which can lead to 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

https://www.apple.com/quicktime/

Details

The function QuickTime3GPP!0x37D0 is responsible for parsing samr atoms inside the file.

After the 4CC of the atom is checked, there is a check to ensure the atom is at least 0x24 bytes in size.

56  v4 = *(_DWORD *)(*(_DWORD *)stack_loc + 4) == 'rmas';  //Check 4CC
57  LOBYTE(v34) = v2;
58  if ( v4 )
59  {
60    v23 = *(_DWORD *)v3;
61    HIBYTE(v5) = BYTE2(v23);
62    LOBYTE(v5) = *(_BYTE *)(v3 + 3);
63    if ( ((((unsigned __int16)(v23 & 0xFF00) | (v23 << 16)) << 8) | v5) - 36 > 0 ) //size check
64    {
(...)

No additional size check is performed to evaluate whether the atom size is large enough for there to be data past the initial 0x25 bytes. As long as the size is > 0x24, the code will attempt to read the bytes at offset 0x28, expecting an additional 4CC.

The following pseudocode checks for a “damr” subatom, and then attempts to copy 9 bytes into a destination buffer starting at 0x2c bytes into the atom.

88        v11 = *(_DWORD *)stack_loc + 40;  //Use offset 0x2c into the damr atom
(...)
92        if ( (*(_BYTE *)(v11 + 3) | v12 | (((unsigned __int16)(v23 & 0xFF00) | (v23 << 16)) << 8)) == 'damr' )
93        {
94          v42 = 0;
95          v43 = 0;
96          v44 = 0;
97          v40 = 301989888;
98          v41 = 'rmas';
99          memcpy_wrapper(v11 + 4, &v42, 9); //memcpy 9 bytes from object offset 0x2c

A “samr” atom with “damr” component must be 0x35 bytes long, however, the atom size controls the size of the source buffer passed to the samr parsing function. Since it contains less than 0x35 bytes of data, and the function contains only a minimum length check of 0x24, the function results in an out-of-bounds read.

Reasonably, the crash could occur here if less than 0x2C bytes were provided. However, since the 4CC check passes, the code proceeds to the memcpy, attemping to copy out an additional 9 bytes of data (0x11-0x8 = 0x9) to a stack address without checking it doesn’t exceed the source buffer.

Conditions for triggering this crash are:

if samr atom size is between 0x25 and 0x2b: A read A/V will occur when attempting to check the 4CC code at 0x28

if samr atom size is between 0x2c and 0x34: A read A/V will occur if the 4CC code “damr” is at offset 0x28

Crash Information

eax=c0c0c0c0 ebx=00000000 ecx=00000002 edx=00000001 esi=0f766ffc edi=002ac104
eip=698c0358 esp=002ac044 ebp=002ac04c iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210297
QuickTime!DllMain+0x5e8e8:
698c0358 8b448efc        mov     eax,dword ptr [esi+ecx*4-4] ds:0023:0f767000=????????

STACK_TEXT:
002ac04c 698f2354 002ac104 0f766ffc 00000009 QuickTime!DllMain+0x5e8e8
002ac088 6e533967 0f766ffc 002ac104 00000009 QuickTime!theQTMLDispatcher+0xdde4
002ac0d0 6e53a7ef 00000000 00000f5f 00000000 QuickTime3GPP+0x3967
002ac5e4 00000000 00000f5f 158d2b66 00001974 QuickTime3GPP!EatTx3gComponentDispatch+0x162f

Timeline

2012-12-03 - Discovery
2015-05-08 - Reported