reply summary (was: odd exploitation question)

[Jeremy Kelley <jeremy () austin ibm com>]

Quoting Jeremy Kelley (jeremy () austin ibm com):
> I'm a little stumped writing an exploit for an ActiveX object and so I
> figured I'd pester this list for a bit of help.
>
> My exploit works flawlessy when attached to the process in the
> debugger.  Doesn't exec calc.exe when run w/o a debugger.
>
> Questions:
>
> 1) The heap is different when run under a debugger (thx HD for the
> tip), but, I'm attaching the process with Olly _after_ it's already
> running.  Windows doesn't do some whacked-out mojo and start using the
> debug-heap on any heap allocations following, right?  I can't fathom
> how that would work.

No.  The heap does not magically change when attaching a debugger.
All is right with the world.

> 2) What could cause the shellcode to execute flawlessly under a
> debugger but not other times.  It's an exec - so I can't imagine the
> process is dying before it's kickstarted calc.exe.. exec doesn't work
> that way.

Elves, Tom Cruise, or maybe Oprah Winfrey.  I'm not sure which, but I
still hold that it's one of these.

Apparently in the debugger, I was passing some exceptions off back to
the app while others I wasn't (I'm not sure what I was doing with
them, but well..) and that seemed to cause corruption on my stack
_after_ my shellcode had started due to exceptions being thrown by
functions called by my sc.

The recommendations I received off list to my plea were quite helpful.
Here's a summary:

1) use heap spraying.  
 * Didn't do this.  Instead, we figured out what address we were at
 * during runtime and made sure everything played nice.  It appears we
 * were croaking in a mucked up exception handler at runtime, but in
 * the debugger was sidestepping that one/giving it time to clean up
 * things.  I have questions about the way that threads/exceptions
 * work together that I'll be researching in the next few weeks.

2) set first instruction to int 3, then set runtime debugging
 * In this instance, if the shellcode was hit, it was a munged copy of
 * that shellcode and so INT 3 wasn't a viable option

3) make sure msvcrt is being loaded
 * I was good here.  Thinking along these lines made me wonder what
 * other dlls I could get loaded into the address space so that I had
 * more fun to work with.

4) use \xeb\xfe (itty bitty jmp back) so you get an infinite loop
 * This was invaluable when I was trying to find the state of the
 * stack at the point the shellcode was finally being reached.

I'm supposed to give a _shout-out_ at this point to rider, on my team,
since he went w/o sleep for I don't know how long until he found that
magic bit that made it all fall together.  If you ever need some
really snazzy PowerPointFu, he's your guy.

I'd like to say what we were attacking, but, well, I can't. I will say
it's an activex that runs in IE.  The exploit now works completely
reliably on w2k sp0-sp4 and wxp sp0,sp1.  WinXP sp2 is still being
difficult, but it seems to work more than half time there.  All in
all, it really is a tame vulnerability, but it really became one of
those kinds of things where you're racing your team on because you
want to be the first one to get it.  Literally, I was dreaming in hex
at certain points because this drove me nuts.  Guess I'm admitting my
lameness there... ;)

That's my recap.  Thanks all for the great replies and help.  In
particular, thanks for your patience to those who replied to me off
list on multiple occasions.

jeremy

-- 
Jeremy Kelley <jeremy () austin ibm com>        Threat Assessment Analyst
gpg  1024D/E0DF8B2D  4BC3 B8B5 5B42 CC8E B6A9 2E85 32D3 C51C E0DF 8B2D
That's the problem with science.  You've got a bunch of empiricists
trying to describe things of unimaginable wonder.      -Bill Watterson
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave