[<prev] [next>] [day] [month] [year] [list]
Message-ID: <F6242D340921D5118D1E00508BB9837A07658141@tlnmail1.toplayer.com>
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
Powered by blists - more mailing lists