SoylentNews is people
SoylentNews
from the he-who-does-not-learn-from-history dept.
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 Foobar Bazbot on Saturday October 11 2014, @05:15PM
I don't have numbers either, but AIUI it goes much farther than a putative real-world CGI service implemented directly in bash. (Which I'm with you on. Perl, sure. Maybe ruby or python, if that's your thing. Personally, I could see doing it with awk, because dammit, I like awk. But bash? WTF would ever make you do that?)
The point is, once an attacker puts the exploit in your CGI script's environment as HTTP_FOO, it not only applies to the CGI script itself, but is commonly inherited along with the rest of the environment by child processes. If the CGI script or any child process eventually executes /bin/bash (or /bin/sh on many systems), whether explicitly or implicitly, you get bit. In C terms, I mean by "explicitly" something like:
and by "implicitly" something like:
or
I'm not familiar with perl's facilities for executing external commands, but I assume that, like many languages, it has both system()-like and exec()-like facilities. Even if not, or if your code only uses the exec()-like version, it may implicitly spawn a shell by execing a shell script, and of course any program it does call may also start a shell implicitly or explicitly.
(Score: 3, Informative) by maxwell demon on Saturday October 11 2014, @07:41PM
However, system invokes /bin/sh which need not be bash (and at least on Debian-derived systems is not bash). And a shell script, unless it explicitly requests bash in the shebang line, will also be executed using /bin/sh.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by fnj on Sunday October 12 2014, @06:38AM
(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
(Score: 2) by chromas on Sunday October 12 2014, @09:32AM
SedBot weeps in the corner.
And think of all those init scripts! So you see? Systemd was trying to save us all along!