[Dailydave] reply summary

[Jared DeMott]

Jeremy Kelley wrote:
> Quoting Jeremy Kelley (jeremy at 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
>   
Remember stack protection and safeSEH for xpsp2.  I'm tell ya, give the
spraying a try -- it's simple and works well on IE.
> 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
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20060902/fa1aa0ce/attachment.htm