RE: Vulnerability Response (was: BGP TCP RST Attacks)

["Ben Nagy" <ben () iagu net>]

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of Paul D. Robertson[...]
>
> That's a function of being in the room when $vendor proclaims 
> that their code is the only code ever written securely.  
> Asking for proof (or better yet formal proofs,) metrics, 
> measurements and independent assessments and explanations of 
> how they handle specific circumstances wins almost every 
> time.  "How many bugs/kloc do your coders produce?"  "What's 
> the number of bugs in your bug database for $product?"  What 
> happens if there's a bug in your interface and someone does 
> the following..."

Current vulnerability research is finding lots of lots of amusing ways to
make software fail in spite of "Secure Development Practices". 

The thing is that even good methodology can create bugs that are nearly
impossible to find with manual or automatic code auditing tools - as long as
your language lets you directly screw around with memory and your
architecture lets you treat arbitrary memory as code things will continue to
suck. That's why the job is easier for the attacker - they don't care why
things fail, they can just hammer on things until they break, and if the
process if well enough instrumented they can start working back from the
fault to then find out if/how they can craft input which will trigger it in
an interesting way.

Sure some attackers will use static analysis or "redpoint" and look for
unsafe calls, pointer arithmetic and the like - but techniques like fault
injection with input fuzzing are quick, dirty but sadly very effective.
Rather than measuring on (known) bugs/kloc I think it would be better to ask
"What is your approach to fault test your own object code?", "How do you
plan for component failure" and that kind of thing. Vendors that don't test
their code using the same methods as attackers will get 0wned. This is why
we're still seeing some security vendors with their names up in lights on
bugtraq. (You were probably about to say all this but replaced it with ...
:)

To hark back to my original point >grin< .... this is why I see value in
"stuff" that can mitigate standard vulnerabilities, or block standard
attacks. It turns out to be a lot easier than waiting for every software
vendor to do the right thing. This goes way beyond "personal firewalls"
though, and is where people start talking about IPS, then things get vague,
then people do marketing hand-waving, then Marcus gets mad, and then, and
then...

For a couple of really fun reads on the vulnerability angle, I really like
Hoglund/McGraw "Exploiting Software" and "The Shellcoders Handbook", which
are both recent and both written by real researchers.

This thread has been kinda fun. We've got enough soapboxes to build a couple
of carts now. ;)

Cheers,

ben



_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards