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".

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.

>"Apache sets environment variables, it does not pass user input directly to bash as code or anything like that." //

This is contrary to how I'm understanding the situation. BASH, or whichever shell is being used, sets environment variables; Apache httpd et al. pass off some user data (from clients, eg browser headers) to the shell to set variables under limited circumstances [like use of CGI], no? Then when BASH gets initialised something is happening in the parsing of variables causing statements included with the variable (which variable can be a function definition) to be executed.

I realise now that as things stand you can't sanitise many of the fields [like http client headers] as they don't have well defined forms. But setting variables for use by BASH seems as close to "pass user input directly to bash" as you're going to get.

Mainly I'm doubting that all these different apps duplicate code to set env variables when the shell already knows how to do it, doesn't seem very *nixy. Happy to be corrected as I'm - as I'm sure you've guessed - a bit out of my depth.

Sorry for the late reply - you can think of environment variables as basically HTTP headers for bash scripts. They are one way to pass user input to a bash script. While you want bash to make those environment variables available to the bash script, you don't really want any code in their value to be executed (unless, of course, your script does that on purpose).

httpd with CGI does not alter your bash script by prepending a set of variable assignments (which, of course, would be a very bad idea) - it simply sets values that are then passed to bash. The bash parser then can be tricked into executing code in those environment variables.