I can't understand something about Shellshock bug - if these environmental functions (which declaration begins with "()" ) are executed on the shell start, how does the patch prevent the problem?

We can still set some function through HTTP headers, and the next time when on the server someone opens Terminal for example (when bash loads), the body of the function will be executed, even when the parser doesn't run arbitrary commands after the function body (like in unpatched version, where we invoke bash with 'bash -c :' and get the RCE immediately).

The name of the variable that holds the function shouldn't matter.

what is the difference if it will be 'x' or 'HTTP_COOKIE'? Can someone explain me?

1 Answer 1


Bash has a feature whereby it interprets some environment variables as function definitions. For example, with the environment variable HTTP_COOKIE set to () { echo hello; }, bash parses the value of the variable as a function definition, as if the script had started with HTTP_COOKIE () { echo hello; }. The body of the function is not executed, unless the script calls HTTP_COOKIE as a command: it's the function definition that's executed.

The Shellshock vulnerability is due to interpreting the variables as more than function definitions. For example, if HTTP_COOKIE is set to () { echo hello; }; echo pwned, then bash parses and executes the function definition when it starts up, and happily goes on to execute the rest of the content of the variable, so it executes the instruction echo pwned.

With the Shellshock patch, only well-formed function definitions are accepted. A value like () { echo hello; }; echo pwned is rejected because it contains trailing code after the function definition.

The script must be written carefully and not use HTTP_COOKIE (or whatever variables have content that may be chosen by an adversary) as a command name. Only variable names that are used as command names by the script can lead to code injection: variable names that are used as variables or not used in the script are not a problem.

An environment variable defined in a CGI script has no influence whatsoever on a shell started in a terminal. Environment variables affect processes and are inherited by subprocesses, they don't somehow magically jump to other processes that happen to run the same application.

  • And when bash starts on the remote side? Can we force that if we apply the attack remotely? Sep 26, 2014 at 11:12
  • 2
    @programings I have no idea what you're asking. When bash starts, then what? Sep 26, 2014 at 11:39
  • Thanks Gilles, you're really good at explaining stuff. This isn't the first time I see one of your answers and it clears up my doubts. Oct 1, 2014 at 19:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .