eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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 theres something dishonorable about choosing languages that prize safety over pure efficiency. Hardware capacity is growing faster than programmer accuracy. Its 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 dont 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 wont be found; CPU and language creators need to continue research into just-in-time compiler performance; and customers need to speak with their wallets. Its time for new thinking about how critical software is created.