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

[Joseph Steinberg <Joseph () whale-com com>]

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

Use an application-filtering tool/proxy that employs positive logic. Only
requests that conform to what the daemon expects will be let to pass
through. (You can protect the app-level-inspection engine with other types
of security -- such as Air Gap)... 

JS


-----Original Message-----
From: Darren Reed [mailto:darrenr () reed wattle id au]
Sent: Tuesday, August 07, 2001 11:42 AM
To: adam () homeport org
Cc: darrenr () reed wattle id au; Joseph () whale-com com;
rcwash () concentric net; firewall-wizards () nfr com
Subject: Re: [fw-wiz] Re: Code Red: What security specialist don't
mention in warnings(Frank Knobbe)


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