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

[Adam Shostack <adam () homeport org>]

On Wed, Aug 08, 2001 at 01:42:25AM +1000, Darren Reed wrote:
| 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 ?

Clearly, you don't understand my message.  If you look at the tools I
mentioned, you'll see that they are code scanners, not vulnerability
scanners.   A code scanner (ITS4, RATS) examines the source code to an 
app to find calls to dangerous functions, etc.  A vulnerability
scanner (ISS, Nessus), goes out and looks for evidence that a system
has a known vulnerability.  Tools like Stackguard add "canaries" to
make exploiting stack overflows more difficult.  There are papers on
all of these tools out there; I suggest that you read them.

| > 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.

If you've ever studied software engineering, you'd know that the use
of standard tools helps workers concentrate on the unusual cases, and
is considered a useful practice.  I don't see why you're down on the
idea of automatic bug detection as part of a baseline due-care
standard.

Regression testing only looks for bugs that have been found before, to 
ensure that you don't regress.  Unit tests, in my experience, fall
into two sets; those written by the engineer who wrote the code, which 
never find anything until the code is handed over to someone else,
because the engineer already dealt with the cases that he wrote tests
for, and those written by a junior QA guy, which find fenceposts, and
off-by-one and that sort of thing.  Neither tends to find security
flaws, unless you have a really unusual person writing the tests.


| 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.

I expect that the use of RATS would be helpful in finding those cases,
as it looks for fixed buffer sizes in code, etc.

For example, it points out that ipfs.c calls strcpy a bunch of times.
As an auditor, I can go look at those lines and see if they're ok.  At
a higher level of repeatability, I can wrap RATS in a program that
detects changes in the output of the scanner, ensure that RATS is
called in the makefile and/or cvs, etc.  And I think that failure to
do so today is showing a lack of due care in creating software.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume


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