Re: We have met the enemy, and the enemy is ...

["Sandy Wilbourn" <srw () determina com>]

I don't mean to be a vendor shill on the list, but you asked...

> Date: Tue, 11 Apr 2006 15:05:33 +0200
> From: Joel Eriksson <je () bitnux com>
> Subject: Re: [Dailydave] We have met the enemy, and the enemy is ...
>       you.
> To: "Knape, Joe" <joe.knape () cingular com>
> Cc: dailydave () lists immunitysec com
> Message-ID: <20060411130533.GB19767 () eip bitnux com>
> Content-Type: text/plain; charset=us-ascii


Joel wrote... 
> Specifically I don't see how the "program shepherding" technique
> would protect against overwritten function pointers, when still
> pointing them into valid functions (e.g. not injected shellcode)?

"Shepherding" protects against any 'branch instruction' that jumps into
somewhere 'unusual' so function pointers do apply here.  If you jump
into a valid function, we'll normally catch it using a set of heuristics
about what addresses are 'legal' to call from a given point in the
program. It takes into account imports, analysis of the actual module,
etc.  Some of the techniques that we use are described in Vlad's
original MIT paper.

> I also wonder if the Determina implementation protects the code
> cache memory during all times that application code is executed
> or if that has been removed for optimization purposes? How large
> is the slowdown by Determina now btw?

The product does protect the code cache memory. The extent to which it
does this does vary by which options you have set and what we think
could be easily attacked.

You can construct programs that will slowdown a lot. However, the good
news is that most programs (e.g. web servers) that are out there aren't
much effected by running under our product.  

In all cases and with all products in this space, I would recommend that
a customer go through a testing cycle with the kinds of
applications/systems you expect to protect. I've seen a lot of variation
through doing competitive analysis if nothing else.

> Some reading for those of you that didn't know that Determina
> is based on techniques that were originally developed using the
> DynamoRIO framework:

> http://www.cag.lcs.mit.edu/dynamorio/
> http://www.burningcutlery.com/derek/docs/phd.pdf
> http://www.burningcutlery.com/derek/docs/security-usenix.pdf

> A question to the Determina people (that I know are present on
> this list): Is Determina still using DynamoRIO code or has everything
> been implemented from scratch?

Yep, we started with the DR code, but it has been a couple of years now
so there have been a few changes :)

> The biggest flaw with this technique is that a kernel bug would
> circumvent it completely though. Of course, kernel bugs are game
> over anyway, but since kernel bugs are getting pretty popular
> and since Determina gives the impression of protecting against
> pretty much everything it should be pointed out.

We don't claim to protect against kernel vulnerabilities unless they use
techniques that come back into user space and manipulate the execution
flow.

> As with pretty much any other vulnerability protection technology
> it also can't protect against logical bugs and other bugs that
> doesn't rely on direct execution flow manipulation.

> The conclusion, as expected, is that people still need to run
> software (and operating systems) with an originally secure design
> and implementation. :)

> Very interesting research though and I hope the Determina people
> here can answer my questions.

Hope the above helps...

Regards,

Sandy Wilbourn
VP Engineering, Determina
srw () determina com