Control EDX/EAX in JPG Heap Overflow (MS04-028)

["Elia Florio" <eflorio () edmaster it>]

Hi list,
I'm tryin' to study Heap Overflow mentioned by MS04-028 in GDIPLUS.DLL library.

After some test, I've found that the position of dword able to
control EDX register (as Nick D. said) is on the 5th DWORD,
counting after the malformed "FFFE0000" header.

A malformed JPEG header looks like this :

;------------------------------------------------------------------------
FF D8 FF E0 00 10 4A 46 49 46 00 01 00 00 00 01;    ÿØÿà..JFIF......
00 01 00 00 FF FE 00 00 41 41 41 41 41 41 41 41;    ....ÿþ..AAAAAAAA
41 41 41 41 41 41 41 41 43 43 43 43 41 41 41 41;    AAAAAAAACCCCAAAA

....jpeg format continues....

;------------------------------------------------------------------------

It's possible to use "FFFE0001" or "FFFE0000" as invalid comment length 
to force the heap overflow. The overflow is raised when GDI+ calls to NTDLL.RtlFreeHeapW
When we land in the exception area, OllyDbg shows this invalid instruction :

MOV DWORD PTR DS:[EDX], EAX

In this point we can control the value of EDX (it's overwritten by "CCCC" 0x43434343 dword inside JPEG header), but 
it's difficult escape from the heap and take the full control on execution.  

I've found the DWORD "28F0B600" used in the JPEG header in place of "CCCC", 
(reading it in reversed form is the 0xB6F028 address) can point [EDX] to the 
stack area and can be used to write here the next return value popped from 
RETN 0C instruction. This helps to control the execution flow from this point,
however when RETN 0C is executed, the IP will jump to EAX value that was stored 
in [EDX] before. Not good.... :(

Has anyone studied the overflow? Any suggestion???

[eflorio]