It's Time to Abandon Insecure Languages

R. A. Hettinga rah at shipwright.com
Thu Jul 18 01:26:44 EDT 2002


http://www.eweek.com/print_article/0,3668,a=28859,00.asp


eWEEK

July 8, 2002
It's Time to Abandon Insecure Languages


The security of the internet took a one-two combo to the gut last month
when we learned of remotely exploitable security holes in Apache HTTP
Server and OpenSSH. The costs of these two problems could be enormous-the
foundation of the worst Internet worm yet-and should prod us all to rethink
the way security-sensitive software is written.

Apache currently runs 56 percent of the sites on the Internet-more than 21
million domain names-and OpenSSH is the padlock used to protect the most
security-sensitive servers in an organization. Patches for both were
quickly made available, but those patches must still be applied, and until
they are, sites will remain vulnerable.

However, we need to look at the deeper implication-that even in the most
successful security-conscious projects, serious flaws can remain buried for
years and then claw their way up through the dirt for our blood.

Both these problems are due to our old nemesis, the "buffer overflow" that
lets rogue code sneak in through a door marked "data." These holes
demonstrate that we must switch to writing security-sensitive code in
managed environments, like the Java virtual machine or .Net run-time, that
continually enforce code/data distinctions.

We have to get over the bias that there's something dishonorable about
choosing languages that prize safety over pure efficiency. Hardware
capacity is growing faster than programmer accuracy. It's time to require
case-by-case justification of C and C++, the tools that grease the floor
and let developers run with knives.

What we don't need are cocksure code cowboys who stick with insecure
languages because they think they can do better than the Apache or OpenSSH
development teams. The correct lesson is that even exceptionally skilled
security fanatics, poring over source code line by line, year after year,
still make mistakes.

Developers need some steel in their spine to commit to safety before other
goals; ISVs need to stop taking chances their bugs won't be found; CPU and
language creators need to continue research into just-in-time compiler
performance; and customers need to speak with their wallets. It's time for
new thinking about how critical software is created.





Copyright (c) 2002 Ziff Davis Media Inc. All Rights Reserved.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list