Dailydave mailing list archives

Re: DFlow Managed language?


From: Mario Santana <msantana () terremark com>
Date: Fri, 11 Sep 2009 11:03:30 -0400

dave <dave () immunityinc com> wrote:

One thing you could do is add a trust level to the data going through
your managed language code, and if the data is trusted, have it go
through the native code, and if not, go through the slower managed code.

More generally, you could break it down into three pieces.  First, you've got to decide how much you trust the data.  
You could key off of metadata (e.g., jpgs with commentary I recognize as being from my camera,) or you could decide 
based on some rule set (e.g., this connection didn't port-knock correctly, or even (gasp!) some IDS.)  For a web app, 
for example, you could use mod_security to mark a session as suspicious if it tries anything funny.

The second piece is forking that data stream down an alternate code path, based on how much you trust it.  This could 
be built into any spot along the stack that the application is built on.  You could do it in the language, or the API, 
or at the network level for client/server apps, or whatever.  For web apps, you could use a reverse proxy to redirect 
suspicious sessions to another instance of the web app stack.

The third piece is doing something interesting in the alternate code path.  You could have two different 
implementations of a parser, like you mention.  But it might be easier to just have another instance of the same code, 
but heavily instrumented.  You could also make it so that the alternate code path is sandboxed away from sensitive 
stuff, depending on how sure you are that the untrusted data is malicious.  Notice that instrumentation plus sandboxing 
would make the alternate code path a honeypot, basically.  For PHP web apps, you could use HIHAT.

In case you're wondering why I put the lame web apps examples in there - I'm working on a poc to do this.  Not too 
tricky, just can't seem to find the time to finish it.  (Dave, maybe you can talk to Chris about giving me more time 
for cool research.  ;-)

Anyway, I've been thinking about this sort of thing because it's the only interesting direction of thought I've come up 
with to answer a key security question; namely, given the fact that someone somewhere has an 0day for something you 
run, how can you keep secure?  Misdirection is the only answer I can think of.

See you all in a week or so at Hacker Halted.

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


Current thread: