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: 2) by choose another one on Saturday October 11 2014, @10:01PM
It goes further than CGI as well. The unix way means implementing services as pipelines of lots of different programs, and environment variables pass all the way through. Any program in the pipeline may be a shell script or may use system() etc. Often shell scripts are part of the pipeline specifically to allow user customizability.
Think ".qmail" for instance (man qmail-command). In fact several (most) mail servers are vulnerable. Just as one example, other services are vulnerable too.
(Score: 2) by fnj on Sunday October 12 2014, @06:41AM