It appears that this issue is caused due to a flawed attempt to perform bounds checking. When data is read in from the server Quicktime executes a function at 0x6761d530 (QTCacheComponent_ComponentDispatch+80b0) which copies the data to the heap. This function takes 3 arguments the source buffer the destination buffer and a length value. The issue seems to be the caller of this function passes the strlen() of the source buffer rather than the size of the destination buffer.
The following is the disassembly of the copy:
loc_6761D550:
mov al, [ecx]
mov [esi+ecx], al
cmp byte ptr [ecx], 0
jz short loc_6761D560
inc edx
inc ecx
cmp edx, edi
jb short loc_6761D550
This would be equivilent to the following:
strncpy(dst, src, strlen(src));
Obviously this is not correct. This causes a very large overflow which can overwrite several heap chunks.
As covered in several publicly available papers this can easily be exploited on Windows 2000 and prior if the overflow runs into a free heap block an attacker could overwrite the heap management structure used to unlink a free block from the doubly linked free list. This allows for a 4 byte arbitrary overwrite. Windows XP SP2, Windows 2003, and Windows Vista present more of a challenge for exploitation in this fashion. This is due to additional sanity checks performed during the unlinking of free blocks from the free list within the RtlFreeHeap() function.
As of right now I have not found a way to successfully exploit this issue on my test machine running Windows XP SP2. It does however, appear that the exploit code I do have would yield code execution on Windows 2000 SP4 machines. I have two possible options for XP SP2. I could try to either find a way to reach a code path which if hit would cause the free block to be placed on the lookaside list rather than the free list. This would allow me to bypass the checks. The other option seems to be overflowing into a block containing a critical section linking structure and perform a similar attack on that structure.
I'm still investigating the methods of exploitation on Windows XP SP2. If I do manage to get code execution I'll post my conclusions so keep an eye out.
