5 ms·

CGI scripts is the most obvious way - when executing a CGI script, each HTTP header gets translated into an environment variable - but I have no doubt there's a

CGI scripts is the most obvious way - when executing a CGI script, each HTTP header gets translated into an environment variable - but I have no doubt there's all sorts of odd network-facing apps which set environment various and then run a command, even if you're not running CGI scripts.

pbhjpbhj 12y ago
Surely though the CGI framework sanitises the headers first? Otherwise this seems like it's a pretty predictable problem - isn't "always sanitise user data" the cardinal rule of backends. I can certainly imagine that I might have designed a web page that passed user input direct to a BASH script to do a ping or some such, but not if it's public facing.
- SwellJoe 12y ago
  One of the comments in this thread (http://seclists.org/oss-sec/2014/q3/650 http://seclists.org/oss-sec/2014/q3/650 ), seems to indicate that Apache is an attack vector for this vulnerability.
- AgentME 12y ago
  What sanitization do you expect the CGI framework to apply to the header value representing the user agent? str_replace($userAgent, '() {', 'no bash bug for you')? Only a few environment variables are given any meaning by the system. Other environment variables don't have any predefined meaning and can be any null-terminated string.
  - pbhjpbhj 12y ago
    Indeed, lol. It's a bit clearer to me now. Thanks for your comment. It seems like a sort of loose typing issue. Perhaps if when setting environment variables the app using them could specify a type (eg nonExecutableText) such that bash knows it's receiving textual content that mustn't be executed; would that help?