Re: Fwd: RE: We have the enemy, and the enemy is... you

[Chris Wysopal <weld () vulnwatch org>]

On Thu, 13 Apr 2006, Olef Anderson wrote:

> I hope this non-formal thoughts will help some of you, responsible for
> making such decisions, see the perspective of a security researcher
> whose sole job is to break systems on a daily basis and who came to a
> point that he sees that MS is standing in a better position than the
> vendors claiming to cover its soft spots (yes! including you AV/spyware
> industry).
>
> Ok, finally here are some reasons why i bother with championing MS over
> HIPS in this lengthy email (for my standards at least);
>
> -  As somebody making a living finding and writing exploits, I am having a
> harder time exploiting a heap overflow against a service running on 2003 SP1

I agree with what you are saying up to this point. Use DEP supported
hardware. Use autoupdate. You are right about MS regression testing.  It
isn't perfect and there are rare problems but it is more reliable than the
changes and testing required for a run time 3rd party solution.

But what Determina et al. are protecting against is not just Microsoft
developed code (mostly IE).  It is other 3rd party apps that are not
developed with the Microsoft process or more correctly nothing even close
to that process.

> -  HIPS making exploitation easier and sometimes even much reliable
> by not protecting their own metadata. rw- function pointers,
> .data turn-me-off dwords/bools, just to name a few  ...
>
> - A much weaker code security assurance process than MS (has anybody
> followed Mr. Wheeler's track record against AV recently ?), meaning
> opening room for more vulnerabilities, in a product thats suppose to
> prevent them. Such a tragicomedy!
>
> - Personally being against in securing protocols and services by writing
> filters on top. Filters, meaning more parsers, doesn't really help with
> the problem, if not make it worst, hint my prior comment. In recent
> years, after enough embarrassment, MS is doing a decent job securing its
> own code base and protocols. And I would take that as an assurance
> rather than some under-payed researcher/developer determining which
> functions to hook and what to check against (dear vendors, I know how it
> works out there, don't bore me with rhetoric ;) )

Your position that the wrappers have to be at least as securely developed
as what they are protecting is well taken.  We have seen people get owned
by installing a particular security component that wasn't well written.
It is incumbent upon vendors that install code on your host to show that
they have a process at least as good as the flawed code they say they are
protecting.

-Chris


> Regards,
> Olef.