The 'ShellShock Bug' (patched 2014)...

From the researcher that actually found the bug...
  https://unix.stackexchange.com/a/157495/68648

'Inherited functions' are subverted so as to always execute, immeditally on
shell start up, BEFORE a shell script has a chance to sanitize its
environment.

Basically by have it execute code that appears after the 'inherited function'

  env x='() { echo :; };  echo cracker code'  bash -c 'echo sub-shell'

Would Output...

  cracker code
  sub-shell

That is the crackers code ran BEFORE the shell script!


ANY environment variable can be used for this!

As such ANY environment variable can contain code that can be used to attack
a vunerable BASH sub-shell call. For example
  OpenSSH...
     The TERM environment variable
  Apache CGI scripts
    A typical HTTP request looks like this:

      GET /path?query-param-name=query-param-value HTTP/1.1
      Host: www.example.com
      Custom: custom-header-value

    The CGI specification maps all parts to environment variables.  With
    Apache httpd, the magic string “() {” can appear in these places:

      * Host (“www.example.com”, as REMOTE_HOST)
      * Header value (“custom-header-value”, as HTTP_CUSTOM in this example)
      * Server protocol (“HTTP/1.1”, as SERVER_PROTOCOL)


The 'ShellShock' BASH patch fix the bug by having 'inhertied functions' stop
interpretation at the end of the function definition ( the closing '}' ).

However a second patch added a prefix to the variables that are used for BASH
inherited functions, so only specific variables can be used to define function
in a sub-shell, and not just ANY variable.

Exported functions now have the form...
  'BASH_FUNC_name%%'='() { ......; }'

For example...
  env 'BASH_FUNC_foo%%=() {  echo foobar; }'     bash -c foo
  foobar

  env - 'BASH_FUNC_foo%%=() {  echo foobar; }'   bash -c "declare -x -F"
  declare -fx foo

Functions exported from bash do not need to be modified, they automatically
generate the environment vaiables of the correct type to run in sub-shells.

The third patch fixed the identifier syntax used, so functions must have a
valid function identifier.  A function using a 'path' cannot be used.

  env - 'BASH_FUNC_2func%%=() {  echo foobar; }' bash -c "echo running"
  bash: error importing function definition for `BASH_FUNC_2func'
  running

  env - 'BASH_FUNC_func-2%%=() {  echo foobar; }' bash -c "echo running"
  bash: error importing function definition for `BASH_FUNC_func-2'
  running

  # valid function identifier
  env - 'BASH_FUNC__fF2%%=() {  echo foobar; }' bash -c "declare -x -F"
  declare -fx _fF2

---

A more extreme test that broke the first round of patches...

   env X='() { _; } >_[$($())] { echo hi mom; id; }' bash -c :

From http://lcamtuf.blogspot.de/2014/10/bash-bug-how-we-finally-cracked.html

-------------------------------------------------------------------------------