You don't need to be using bash explicitly for this to be an issue. The real problem is allowing attackers to have a say in the value of environment variables. After the environment is set, it's only a matter of time before some shell gets executed (maybe unknown to you) with an environment it was not prepared for.

Every program (bash, java, tcl, php, ...) has this signature:

int main(int argc, char** argv, char** arge);

Developers are in a habit of checking argc and argv for cleanliness. Most will ignore arge and make no attempt to validate it before spawning subshells (explicitly or implicitly). And in this case bash is not correctly defending itself from bad input. In order to wire an application together, subprocesses get spawned. At the bottom of it, something like this happens:

//We hardcoded the binary, and cleaned the arg, so we assume that //there can be no malicious input - but the current environment is passed //in implicitly. execl("/bin/bash", "bash", "-c", "/opt/initTech/bin/dataScrape", cleanedArg, NULL);

In your own code, there may be no references to bash. But perhaps you launch tcl, and something deep inside the tcl code launches bash for you. It would inherit the environment variables that are currently set.

In the case of the vulnerable version of bash, something like this is happening:

int main(int argc, char** argv, char** arge) { //bash's main function .... parseEnvironment(arge); //!!!! read function definitions and var defines .... doArgv(argc, argv); .... }

Where parseEnvironment sees a bunch of environment variable definitions that it doesn't necessarily even recognize. But it will guess that some of these environment variables are function definitions:

INITTECH_HOME=/opt/initTech HTTP_COOKIE=() { :; }; /usr/bin/eject

Bash has no idea what an HTTP_COOKIE is. But it begins with (), so bash guesses that this is a function definition. It also helpfully allows you to add some immediately executed code after the function definition, because perhaps you need to initialize some side effects with your function definition. The patch removes the capability to add side effects after the function definition.

But the whole idea that an environment variable can lie dormant with attacker supplied function definition in it is still highly unsettling!

recieve='() { echo you meant receive lol; }'

If the attacker can cause this variable name to get a value that it supplied, and also knows that it can wait for a bash subprocess to try to invoke a function by that name, then this would be another attack vector.

This is just the old admonition to validate your inputs. Since shells may get spawned as a surprising implementation detail, never set an environment variable to a value that is not tightly validated. That means that any possible program that reads this environment variable won't do something unexpected with the value; such as execute it as code.

Today it is bash. Tomorrow it's java, sh, tcl, or node. They all take an environment pointer into their main function; and they all have different limitations on what they will safely handle (until they are patched).