What does C have in common with a scalding cup of coffee?

Security's Brewing Mess

  • alert
  • submit to reddit

High performance access to file storage

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.

Generation Java

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.

Copyright ©

Author and security analyst Hal Flynn manages the SecurityFocus UNIX focus area.

High performance access to file storage

More from The Register

next story
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts
Bloke behind the cockup says not enough people are helping crucial crypto project
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
US taxman blows Win XP deadline, must now spend millions on custom support
Gov't IT likened to 'a Model T with a lot of things on top of it'
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
prev story


Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
HP ArcSight ESM solution helps Finansbank
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.