Shellshock proves it: CGI must die

Remember that incredibly stupid thing you did a decade or two ago? You wouldn't want to live it down every day. Neither should the Internet

Hammer breaks glass
Flickr

The Shellshock vulnerability has existed for decades. You can bet the attacks that surfaced recently are not the first. No doubt, others used the exploit quietly and told no one. (I’m looking at you, NSA and China -- I know you are watching me and, thus, know I like cat pictures.)

Frankly, this nasty bug in Bash should not be a big deal -- and wouldn’t be if it weren’t for CGI, one of the most widespread, terrible ideas ever invented.

CGI was created at the start of the Web. Along with ISAPI and NSAPI, it offered one of the first ways to create dynamic Web content. However, it essentially turns your HTTP request into a shell call. Why anyone thought giving strangers even limited shell access over HTTP was a good idea, I do not know.

Quickly, CGI gave way to using scripting languages and templating like JSP and ASP, as well as other connectors to stuff like Java, Visual Basic, and so on. Some of these, however, were launched (originally) with CGI -- and a few still are! Worse, part of the original code is still out there.

With CGI, you’re told “here is a loaded weapon, use it carefully” to create really well-written CGI scripts. Obviously, carefully writing and extensively testing software is a stretch in most large projects. Moreover, in the modern business practice, hiring a few really good developers has long given way to hiring as many cheap developers as possible.

The myth of “let’s be careful with this” was smashed with the Shellshock bug. If not for CGI, this bug would be a minor privilege escalation path for users with permissions to kick off shell scripts as root (or other more privileged users). It would not be an “oh, did someone break the Internet again?”-level threat. The issue is that CGI exposes the HTTP headers as environment variables, and since Bash may be kicking off your shell script, anyone on the Internet can do it.

It's time to put CGI to bed. It's time for security audits require it be disabled on the Web server. It's time to rewrite the code in any of the multitude of methods that followed.

Some of those methods may also have bugs, but I do not think stuff that kicks off dynamic Web applications written in hand-coded C is a tremendously great idea. Why? Because it is not hard to avoid buffer overflows and underruns. Actually, it is easy to not avoid them, as long as you aren't writing crap code a decade or two ago with a short deadline and no unit tests.

I can't think of anything I’ve seen exploited more often than badly written CGI scripts. With Bash also needing to be bugless, let’s start removing items from practice that are exposed publicly to all and require the developer to be “very careful” when writing it. Sure, there are other obvious holes in network and computer architectures, but this is one mistake that was stupid at the beginning and has been stripped naked today.

What do you say? Join me in “bashing” (hehe) CGI. Can we start to wipe it off the planet today?

Copyright © 2014 IDG Communications, Inc.

How to choose a low-code development platform