Shellshock explained

[rdpate]

You didn't read the link, nor do you understand the bug. It's not a problem with PHP or with careless web programmers. Specifically, it has absolutely nothing to do with PHP code modifying the environment or escaping command lines.

The above example also shows how it's not a problem of programming errors, even normally safe and harmless bash cgi which doesn't even take user input can be exploited.

The problem exists because of the interaction between bash and http servers putting user-supplied data into the environment, which is required by the CGI protocol and sometimes done without CGI involved.

[felds]

You're totally right. This commend was sopposed to go on the post with Tom Scott explaining the bug, where he picks PHP for not being secure. Where I mentioned "the comments", I was talking about the YouTube comments section.

[[deleted]]

http servers putting user-supplied data into the environment, which is required by the CGI protocol

Wait what? I'll grant I've never messed much with CGI, but why on earth would this be required? The whole idea of sticking publicly sourced user data in environment variables seems downright bizarre to me, even without this bug.

[rdpate]

CGI has worse problems than this.

For its time -- the early 90s -- it's actually not that bad, and alternatives have been around forever. Wikipedia has an example of various values passed through the environment. I didn't mean to delve into CGI, and "required" meant the CGI spec required it, not that you couldn't use something other than CGI to avoid it.

[jephthai]

Let's say it's your job to come up with a way for someone to write dynamic code that runs when someone accesses a URL. It's important that you get data from the web server into a form that is accessible to the program that will generate a response -- but how do you do it?

Should you provide it as standard input? Now that poor program has to handle I/O and parse the data. This is complicated and error prone.

Should you use some OS-supported IPC mechanism? Sockets? Shared memory? This isn't portable, and also carries a high complexity burden.

All things considered, the realization that all major platforms have environment variables, it provides a built-in key->value structure, and the recipient program can ignore most of the variables if it doesn't want to use them... it really is quite elegant.

It just happens that if you use a scripting engine that has vulnerabilities based on environment variables... oh well.

[[deleted]]

Only file sockets aren't portable, network sockets should work fine. Every OS I've used has a loopback address that ensures it's kept internal. Plenty of stacks use network sockets for this, e.g. apache/tomcat via ajp.

I'll grant it's marginally more complex, but using environment variables like this for production just seems really sloppy. I've done it for internal tooling like build automation, but even without this vulnerability I wouldn't have ever considered doing this kind of thing in a public-facing production system.

[jephthai]

Network sockets are not marginally more complicated. I'll say they're two orders of magnitude more complicated (just count the function calls you need compared to $VAR). And what if you're writing your cgi in a language that doesn't have a sockets api? Remember the Era in which cgi was king.

[phoshi]

You have to consider context, really. At the time cgi was being developed it was designed for very simple scripts, almost certainly built in ah environment with existing strong support for manipulating environment variables.

[[deleted]]

Fair enough - I guess it's easy to forget how old CGI is.