Re: My pre-Vegas question to Yuji, et. al.

[Dave Aitel <dave () immunitysec com>]

spoonm () ghettohackers net wrote:

> > It's not nearly that long. Throw some real CPU at it. It's even highly 
> > parallel, if you want. CANVAS is full of crazy things. A compiler, an 
> > assembler, and a lot of other crazyness stuck in between. But using the 
> > real CPU gets you one thing that regex or emulation doesn't - the actual 
> > results. How come your SSL PCT exploit has so many targets? That one's 
> > EASY. :>
> >
> >    
>
> Want to know why SSL PCT has so many targets?  HD, hotel room, cansec, 1 hour,
> overheating laptop, 1 vmware image.  We honestly didn't really care about that
> one, I know we can find better return addresses, but we didn't even really have
> good time to look.  It's been on my list of things to do.
>
>  
Yeah, this is a valid answer - a lot of the exploits in CANVAS are 
getting a going over to make them actually good. After writing Windows 
exploits for two years, I'm better than I used to be, and for sure, the 
rest of the people in Immunity are better than I am now or used to be.

> Well, right, but who said process state is always going to be static.  What
> about dynamic heap, dynamic other stuff.  You could end up finding returns that
> don't actually work.  It does actually take that long, to prevent getting stuck
> in loops, etc, you'd need to set a time out.  What if you miss a return because
> it was just a little bit longer than your timeout?  This is halting type
> problems that have been discussed on vuln-dev etc.
>  
Well, you have to test them, which is a fun part of the whole process. 
Matt was working with using a debugger to restore state, I think, but 
you could as easily have the program click VMWare's "revert" and get all 
the OS Handles back to the previous state, and on a fast machine, revert 
is damn near instantanious.

>  
>
> Well, we can do the same stuff FX does except with memdump.exe.  We just take an
> image of the whole process, and do things offline, which is much faster, has a
> record, etc, etc.  There is no reason to actually stay in the debugger.  Using
> memdump is sooo much faster, and nicer.
>
>  
Caching stuff is faster, for sure, although there's no reason a debugger 
can't cache stuff like that. Ollydbg doesn't, but  Ollydbg is a 
generalized tool and not specialized towards vulnerability development, 
much as its seems so sometimes. :>

> > Yeah, I think emulating or using the CPU is overkill in most cases. This 
> > was part of my question. "Why not just corrolate?" Yuji and co are no 
> > doubt in Vegas already, not reading email.
> >    
> Yeah, it is usually overkill, but taking an intelligent method over a brute
> forcing method is always better.  Even if you could get it down to a week, you
> still are going to be missing things because of your timeout, or some state you
> can control but didn't realize, or wasn't setup right, I mean, there are so many
> things.  Moving your shellcode would mean running it all again, changing the
> length/padding of shellcode, etc, etc.
>
>  
True, although I think you are drastically overestimating the halting 
problem here. Non-emulation has another advantage of being able to 
"trace through" system calls, exception handling, and other fun things.

> Sorry if I came off too much like a dick, but people have been ignoring
> msfpescan and intelligent return address stuff and using indebugger and other
> grand schemes that don't work nearly as well.
>  

That's cool. Critiquing technology is not being a dick in this industry. 
Being a dick is different and clearly demonstrated by many people around us.

> Why does your dcom exploit have so many targets?  That one is EASY.
>
>  

It actually autodetects *, down to alternate ports and OS. Unless you're 
thinking of our Locator sploit, which does have a thousand targets and 
needs to be reworked. The leaked version of CANVAS is about 10 revisions 
out of date. I would ignore anything in it.

-dave

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave