full-disclosure - Working GDI+ JPEG exploit code?

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]

From: kquest at toplayer.com (kquest@...layer.com)
Subject: Working GDI+ JPEG exploit code?

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@...hnetsecurity.com]
Sent: Thursday, October 21, 2004 11:51 AM
To: full-disclosure@...ts.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