RE: Working GDI+ JPEG exploit code?

[kquest () toplayer com]

just a quick comment (unfortunately I don't 
have time to give a more complete comment and
I still haven't had a chance to update my write up
on this GDI+ bug)...

some of those exploits have misleading comments...
they talk about overwriting PEB's lock routine function
pointer, but this isn't what they are doing (note: one 
of the original PoCs actually tried to do that, but it
wasn't really workable because it didn't have a magic
number to get back to the shellcode... you actually 
needed to run it in the debugger and plug in your heap
address during the exception or you had to find your
own magic number). The real working exploits (the ones
that successfully execute shellcode without any external
assist) use a different technique. The two magic numbers
we have here (the ones that end up in the two registers)
do the following:
- the first magic number in the exploit is actually an invalid
  memory address. it's all there's to it... you can replace it
  with "AAAA" and the exploit will work just fine.
- the second magic number is actually a memory address
  in the data section of the gdiplus dll. it seems to be
  a function pointer invoked during the shutdown sequence
  of the gdiplus dll (again... I meant to put the detailed
  info about it in my write-up, but I just don't have time
  right now).

Which exploit are you talking about?

Kyle

-----Original Message-----
From: Keifer, Trey [mailto:Trey.Keifer () fishnetsecurity com]
Sent: Thursday, October 21, 2004 11:51 AM
To: full-disclosure () lists netsys com
Subject: [Full-disclosure] Working GDI+ JPEG exploit code?


I have been testing the code on k-otik's site for the last 3 days and have
been unable to get the
reverse shell technique working. My test environment consists of a winxp sp1
machine in a vmware
session and a fully patched winxp sp2 host machine. The code reliably
crashes explorer when a
directory with a malicious jpeg is browsed, but my netcat listener on the
host never picks up
anything. 

My thoughts now are that because the exploit is heap based, its never
jumping to a point anywhere in
the NOP sleds and thus, never finding my shellcode. I ran it through ollydbg
and see that EDX contains
my SC, but EIP is not under our control so we have no way to point to it. 

This is my first real in-depth analysis, so go easy...

---
Trey Keifer
Security Engineer - Level II
Fishnet Security

Direct: 816.701.2073
Main: 816.421.6611
Toll Free: 888.732.9406
Fax: 816.474.0394

http://www.fishnetsecurity.com




The information transmitted in this e-mail is intended only for the
addressee and may contain confidential and/or privileged material. 
Any interception, review, retransmission, dissemination, or other use of, or
taking of any action upon this information by persons or entities
other than the intended recipient is prohibited by law and may subject them
to criminal or civil liability. If you received this communication 
in error, please contact us immediately at 816.421.6611, and delete the
communication from any computer or network system.


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html