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

> Before the rest of my response, I'd like to make clear that I believe

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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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