spoonm_at_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_at_lists.immunitysec.com
http://www.immunitysec.com/mailman/listinfo/dailydave
Received on Jul 28 2004
Intro
