CVE-2014-6271: Remote code execution through bash

Debian's package manager has the nasty habit of stopping affected daemons before all the upgrades and starting them afterwards, leaving you with serious downtime.

My findings so far: setting User-Agent to that new string and executing a .cgi script complains about: syntax error near unexpected token `newline' in `#!/bin/bash'. (My speculation is that we are in some kind of parsing context where no newlines are expected; none are given on the example bash -c ... line, but when you actually run a script there will be a newline).

I tried to change this to a Python script and instead use os.popen. Well, Ubuntu /bin/sh is "dash" so that's not affected.

I tried to explicitly call bash via os.popen("bash -c 'some command'") -- no go either, as that bash command started by parsing some /etc/bash.bashrc file and complaining about newlines there.

Finally I used os.popen("bash --norc -c '/tmp/file date'") -- and that ended up running "date > /tmp/file" from the CGI script.

I tried replacing /bin/sh by "bash" instead of dash. That now made the CGI script choke on reading some other RC files due to the unexpected newlines in the context bash starts with.

So the question from me still seems to be: what is the weird context setup by that environment setup, and what else can do you with it than to redirect $1 to $0 ?

So it's a sort of injection attack that targets inputs to bash that manage to bypass normal sanitisation?

Apache takes SSL_* headers, say, from a client and simply passes those to BASH and this exploit means that BASH will execute a payload dropped in to the header?Am I close? Wouldn't that also be an Apache [httpd] bug in that it's allowing unsanitised user data to hit the shell?

Similarly are you saying that if I set a LANG variable and SSH to a server that the server will use that variable to give to BASH, even if it's not a recognised LANG variable?

Perhaps I'm misunderstanding as such things would be massive holes any way regardless of this BASH issue.

From the example code at the top of the thread it seems that you only need to affect a single variable, that bash reads, in order to pwn the whole server.

Interestingly on Ubuntu the BASH update for this is rated "medium".

According to http://wiki.bash-hackers.org/syntax/basicgrammar it appears that this is because bash allows functions to be exported through environment variables into subprocesses, but the code to parse those function definitions seems to be the same used to parse regular commands (and thus execute them).

Edit: after a brief glance over the affected code, this might not be so easy to patch completely - the actual method where everything interesting starts to take place is initialize_shell_variables in variables.c and parse_and_execute() in builtins/evalstring.c, so parsing and execution happen together; this is necessary to implement the shell grammar and is part of what makes it so powerful, but it can also be a source of vulnerabilities if it's not used carefully. I suppose one attempt at fixing this could be to separate out the function parsing code into its own function, one which can't ever cause execution of its input, and use that to parse function definitions in environment variables. This would be a pretty easy and elegant thing to do with a recursive-descent parser, but bash uses a lex/yacc-generated one to consume an entire command at once...

However, all in all I'm not so sure this ability to export funcdefs is such a good idea - forking a subshell automatically inherits the functions in the parent, and if it's a shell that wasn't created in such a manner, if it needs function definitions it can read them itself from some other source. This "feature" also means environment variables cannot start with the string '() {' (and exactly the string '() {' - even removing the space between those characters, e.g. '(){', doesn't trigger it) without causing an error in any subprocess - violating the usual assumption that environment variables can hold any arbitrary string. It might be a rare case, but it's certainly a cause for surprise.

It's kind of the equivalent of a web app that basically evals any given GET parameter with a specially crafted value.

Apache sets environment variables, it does not pass user input directly to bash as code or anything like that. The fact that bash can be tricked to execute this code is a problem that needs to be addressed by bash, not any other software.