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: 2) by PizzaRollPlinkett on Saturday October 11 2014, @04:08PM
Do we know yet how pervasively this bash bug was exploited? How many remote access exploits have there been? One server in ten? One in a million? One in a trillion? I can't get a mental picture of how pervasively this bug has been exploited.
I can't wrap my mind around the idea that much critical Internet infrastructure depends on bash. Are there really a lot of CGI programs (which don't sanitize their input) being used on the Internet today? Were there ever? I used to see trivial CGI examples in bash, in books and tutorials, but I just assumed that anyone who actually wrote a CGI program would use Perl. For better performance if nothing else. And even old legacy web stuff is usually not CGI, but something like ColdFusion or original ASP. How many web servers are even set up to run CGI?
How much should we care about shell security? Has anyone ever expected shells to be secure? Compared to, say, the daily parade of credit card data breaches, is bash security an important issue? Or are people magnifying this issue because it's a slow news period?
(E-mail me if you want a pizza roll!)
(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!
(Score: 2) by francois.barbier on Monday October 13 2014, @01:32PM
Here is the code of the shell script it tries to run: http://pastebin.com/6z9gfdSx [pastebin.com]