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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <009201c4a033$590543b0$0200000a@Accenture.com>
From: eflorio at edmaster.it (Elia Florio)
Subject: Control EDX/EAX in JPG Heap Overflow (MS04-028)

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040922/862c8264/attachment.html