David Wheeler has a nice write-up of the many aspects of the shellshock vulnerability in Bash, including a timeline of events and commentary on how to prevent vulnerabilities like shellshock in the future.
He even provides a quick test to see if your shell is still susceptible to shellshock:
To determine if a system is vulnerable to shellshock, run the following refined test on a Unix-like system command line (this should work on any Bourne or C shell):
env foo='() { echo not patched; }' bash -c foo
This will reply “bash: foo: command not found” on a repaired system, while a vulnerable system will typically reply “not patched” instead. The initial “env” can be omitted when typing the command into a POSIX/Bourne shell (including bash, dash, and ash).
The write-up shows that several mis-identifications of the problem were communicated, as well as how multiple solutions were constructed—thanks to the code being open-source.
He also presents a similar type of defect under Microsoft Windows where, in a CMD.EXE window, issuing these commands:
set foo=bar^&ping -n 1 localhost echo %foo%
will not only display the value of the "foo" environment variable, it will also cause a ping command to be executed.
[Update: fixed formatting of code sample.]
(Score: 1) by martyb on Saturday October 11 2014, @03:30PM
Mea culpa. Please accept my apologies for the corrupted code sample. We have been dealing with some issues with how the site escapes various characters into character entities, and I used the wrong HTML elements to bracket the code sample. The story has been updated.
You might be interested in this article: Command-injection vulnerability for COMMAND-Shell Scripts [thesecurityfactory.be]. I highly recommend reading the *entire* article. It provides samples of different ways to make the display or use of environment variables cause one or more commands to be executed.
Wit is intellect, dancing.