Re: Re: Code Red: What security specialist don't mention in warnings(Frank Knobbe)

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Adam Shostack, sie wrote:
> On Tue, Aug 07, 2001 at 09:17:08PM +1000, Darren Reed wrote:
> | How about making it a felony to sell or otherwise provide software for
> | commercial use that contains buffer overflows ?  Or make it something you
> | cannot "disclaim" - it should be part of the exercising of due diligence
> | every software company has to get them out of software before releasing it.
> | 
> | I'm actually half serious about this.
> | 
> | It's time to start raising the bar.
> | 
> | How much does it cost the world to patch these problems up vs the developer
> | to put in place proper testing to find and eliminate these problems before
> | it goes out the door?  How can we allow such a critical piece of modern life
> | to be such a pile of rubbish?  The frightening thing is if you look from the
> | embedded market all the way up to super computers, there are no exceptions
> | in the "has a buffer overflow security hole" category.
>
> I think that, with the advent of automated code scanning tools, (RATS, 
> ITS4) and compiler modifications (stackguard, formatguard), it becomes 
> easier to argue that due care in creating software involves adding
> these tools to your build process, and not releasing code that doesn't 
> scan clean.

Crap.

I don't think you fully understand the problem.  All they can do is find
already known problems.  Tell me how any of those are going to find a
buffer overflow in a new daemon someone writes tomorrow with its own
custom protocol ?

> Before there were standard tools for this purpose, it was harder to
> make the argument--what was ok code or not was a matter of debate and
> personal opinion or style.

Oh rubbish.  If you've ever studied software engineering as a process
you'll know about things like unit testing, regression testing, etc.
That was before "testing tools".  How can space shuttle s/w engineers
produce code of such a high quality yet nobody else?  Answer: their
processes ensure it happens.  They don't need ISS or whatever.

Problem is nobody does much of this.  For example, where's the tests for
each and every libc call to ensure they don't core dump when supplied with
parameters 16k long, etc ?  OpenBSD may be "audited" but what has been done
to make sure it stays that way aside from requiring a human to check every
single change ?  Yes, it might be boring work to setup and maintain, but
the returns, even if only peace of mind, should be worth it.

Darren
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards