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

[Matt Hargett <matt () use net>]

dave wrote:
> BlackHat talk:
> "Payloads intended to execute attacker-provided code typically require a 
> static address of code already existing in the vulnerable process's 
> address space, in order to redirect execution back into code 
...

This sounds like an internal thing I've been working on called Project 
Sirius that I designed while at Sundance this year. 
(Sirius->Black->Blackbox -- I am such a fuqn nerd.)



> 1. What's the actual gain over standard address corrolation methods? 
> Immunity's doing fairly well with just that...done properly, it's pretty 
> exhaustive since valid return addresses are sparce.

What I have done in my implementation of these ideas is to use runtime 
analysis data to seed some of the static analysis with useful data. This 
can be especially useful for heap oriented things. I don't want to say 
too much, as I don't want you guys kicking the shit out of me until the 
2nd prototype is ready. (The first went rather well.)

I submitted a talk to Blackhat Vegas presenting this project and some of 
the really nifty things it enables, but it wasn't accepted.


> 2. Why bother emulating? Why not use the CPU instead of emulating a CPU? 
> Reverting state is fairly easy, especially the state you really need to 
> revert...

Hoglund thinks the same thing, and I disagree. In simple programs, this 
makes sense, but not in anything real world one might get asked to look 
at. The biggest problem I foresee with standard debuggers and/or process 
restoration is the process and OS handles getting out of sync. You can 
do a lot of kernel tricks to try and keep things going, but at that 
point you're modifying the state enough that I think you'd run into some 
false situations with the opposite problem -- handles being kept alive 
for too long.

I have an entire talk ready on this subject; if anyone would care to 
see/hear it, let me know of a willing venue.

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