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: 3, Informative) by tynin on Saturday October 11 2014, @02:20PM
Ah, I see what it is doing now. foo contains everything needed with the ^ escaping the pipeline. Once it is set, then echoing the var will execute it. I need more coffee... :)
C:\Users\tynin>set foo=bar^&ping -n 1 google.com
C:\Users\tynin>echo %foo%
bar
Pinging google.com [74.125.229.168] with 32 bytes of data:
Request timed out.
Ping statistics for 74.125.229.168:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
Ping statistics for ::1:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
(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.