Opinion In 1992, a seventy-nine year old woman sued the McDonald's fast food chain after spilling the entire contents of a cup of coffee in her lap, causing third-degree burns over six percent of her body. Several days in the hospital, intense medical treatments, and a jury trial later, the woman won her case and a $2.7 million dollar judgment, ultimately reduced to $480,000.
Some people jeered at the case, calling it a wanton abuse of the legal system. Others jumped on the bandwagon, finding a lawyer that would sue for whatever circumstance they could find. To this day, whenever the McDonald's coffee case comes up in conversation, people still scoff and joke about it.
The fact of the matter is, the woman was seriously injured. If you fill a paper cup with 185 degree Fahrenheit liquid, cap it with a plastic top and hand it to a senior citizen in a car, you have to assume some responsibility for the outcome.
The most popular programming languages are like that scalding cup of coffee. Accidents in programming will happen, and we can't blame programmers for occasionally getting burned.
Today's programmers are still writing code the same way their predecessors did, using the same languages. A good example is C, a robust, excellent language filled with power and features, that hasn't evolved much since the 70s.
This is silly. I'm not saying the lack of C evolution is a bad thing: when we consider that the language was originally designed for writing UNIX, it has served its purpose more than well. It has advantages in portability over lower-level languages such as assembly, and benefits of speed over higher-level languages. It is a useful tool, and will continue to be useful for many years to come.
But the trade-offs are significant, and we can no longer afford to ignore them. As we've seen again and again, the language makes buffer overflows, and other security holes, far too easy to inadvertently code into a program.
Even the developers of the "secure" operating system suffer with C's faults. Theo and crew continually fix bugs in OpenSSH that result from subtle programming errors. And once they're all "fixed," people with talent for finding bugs, such as Solar Designer, look through the code and the floodgates open again.
Meanwhile, most applications written in C today don't even benefit from the language's strengths.
Consider, for example, a chat client that needs low-level system access or memory management. Can you name one? If it is possible to rewrite chat clients using high-level languages like Java, HTML, and even PERL, we should do it. As it is, we're continually seeing buffer overflow and format string vulnerabilities reported in everything from AIM to mIRC; Epic to MSN Messenger.
How about Web servers? They generally require only one feature: to run fast. However, looking at the 1.3.29 release of the Apache Web Server (which, incidentally, was publicly released on October 28th of 2003 because of buffer overflows in two separate modules), there are over five megabytes of code in the Apache source directory! I say the odds are pretty high that not all the problems have been found and fixed. And as we all know, other Web servers on other platforms fare no better.
That's why I like Java. Java offers all the benefits of a high-level language such as portability and object-oriented design, while it also provides some features similar to lower-level languages, such as byte-compiled code. It's highly portable, and it's supported across multiple platforms and architectures. It has all the makings of a panacea.
Most importantly, security has been a huge consideration in Java's design, with a security manager built into the Java Virtual Machine. The language removes memory management from the programmer's responsibilities, eliminating buffer overflows, memory corruption, and format string vulnerabilities. This design choice alone obliterates the most common cause of catastrophic software vulnerabilities in programs from chat clients to Web servers.
For programs that will encounter contact with malicious users, Java appears to be a great language to use.
But Java isn't without it's own security problems. Time and time again, we have seen vulnerabilities arise in Java that cause the entire security model to crumble. The most recent was reported last week, though it got little press, when the Last Stage Of Delirium reported a vulnerability in Sun's Java Virtual Machine that makes it possible to circumvent the security manager's checking of classes in applets when the class is invoked using slashes between sub-class names, rather than the traditional dots. The problem could potentially lead to applets loading classes outside of the "sandbox" that limits the class's influence. It's a disaster in the making: should somebody write a worm, it could move across different operating systems and architectures.
Problems like this are gravely serious, but they can be fixed in the implementation. The security problems in C and similar languages are endemic.
Programmers must evolve to writing applications in higher programming languages. It is time we face the reality that applications can't be safely written in lower languages. But be it Java, or something else, the shift must be to a language that is safer than a cup of McDonald's coffee. Lest we all get burned.
Author and security analyst Hal Flynn manages the SecurityFocus UNIX focus area.