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]
