Re: secprog Digest 18 Nov 2002 18:35:57 -0000 Issue 113

• Previous message: Andrew Griffiths: "Re: Are bad developer libraries the problem with M$ software?"
• Next in thread: George Capehart: "Re: secprog Digest 18 Nov 2002 18:35:57 -0000 Issue 113"
• Reply: George Capehart: "Re: secprog Digest 18 Nov 2002 18:35:57 -0000 Issue 113"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 19 Nov 2002 16:23:41 -0500
From: David Wheeler <dwheeler@ida.org>
To: secprog@securityfocus.com

> Before the rest of my response, I'd like to make clear that I believe
> that poor programmer education is one of the primary reasons we have
> so many vulnerabilities.

I believe the _MOST_ important step to take today is to get
EVERY software developer trained in how to write secure applications.
It is _CRIMINAL_ that we still permit computer science and
software engineering graduates to graduate without knowing
the fundamentals on writing secure programs! We also need to find
a way to get to those already in the field, or who don't go through
those sorts of college programs.

Most of our programs (open source and proprietary) are written
by developers who are fundamentally unqualified to write software,
because they don't know how to write secure software.

In fact, I believe this so strongly that I wrote the book I just
mentioned ("Secure Programming for Linux and Unix HOWTO",
http://www.dwheeler.com/secure-programs) on my own time, and I
give it away. I make nothing at all on the book! I only the hope that
by widely distributing it, there will be at least a few developers
who will learn how to write secure programs. At least, they'll know
the general principles & common mistakes to avoid, so they'll
generally limit themselves to new mistakes :-).

It would be nice to create better financial incentives, and deal
with other fundamental issues, but
that hasn't worked well in the past. In any case, many
simple defensive measures don't cost more than insecure methods.
I believe that most of the time, the developer simply doesn't know
that there's a right & wrong way, and they do things the wrong way.

> That said, I also believe we would be in
> much better shape if languages protected programmers against
> themselves.

Here I agree; today's languages have too many "sharp edges" that
make it easy to do the wrong thing. I applaud efforts to
create standard languages, libraries and interfaces to make it
more likely that the "right thing" is done.

However, I doubt that creating whole new languages is likely to

succeed. Languages are easy to create, but gaining widespread
acceptance is hard. You'll be more successful in creating or modifying
libraries, or by trying to deprecate/replace incrementally the especially
dangerous capabilities of existing libraries and languages.

Also, it's hard to put all the security issues into a language

or library; uses are far too fluid, so the great capability you put in
today may not be helpful tomorrow. For example: Java has some wonderful
security capabilities for running untrusted applications on clients.
But it's increasingly a server-side language; while in theory its
SecurityManager could be used to create interesting security properties,
in practice it's not done, so Java is not significantly more secure than many
other server-side languages (such as Perl, Python, PHP, C#, etc.).

If your language security mechanisms are too general, people won't really
use them. If they're too specific, they tend to be brittle as
requirements change. It's still worth trying to do, and there have been
some partial successes, but it's not as easy as I wish to create a
"secure language."

It's probably more effective to start with a prioritized list of things that
are especially dangerous in a language, and fix them, instead of going
whole cloth. PHP seems to be going that route; they started out with
absurdly dangerous defaults, such as by default allowing attackers to
control all variable values unless explicitly overridden by a programmer.
In my view, woefully inadequate attention was paid to security when
PHP started. But, to their credit, the PHP developers
are actually changing fundamental language structures
to remove the "sharp edges". You won't have an order-of-magnitude
improvement if you just make small incremental improvements to existing
widely-used languages, but the odds are that by the time you're done creating
your new wonderlanguage, the problem space has changed or you'll find that
everyone else who needed that kind of language decided to a different
(available) language instead. I'd be very pleased to be proven wrong :-).

--- David A. Wheeler
     dwheeler@ida.org

• Next message: Steffen Dettmer: "Re: Are bad developer libraries the problem with M$ software?"
• Previous message: Andrew Griffiths: "Re: Are bad developer libraries the problem with M$ software?"
• Next in thread: George Capehart: "Re: secprog Digest 18 Nov 2002 18:35:57 -0000 Issue 113"
• Reply: George Capehart: "Re: secprog Digest 18 Nov 2002 18:35:57 -0000 Issue 113"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]