For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and the CVE-2014-7169 patch. I will be applying Florian's patch once it or a similar patch come out for 3.2.<p>Repository and instructions to reproduce without trusting me are located here:
<a href="https://github.com/ido/macosx-bash-92-shellshock-patched" rel="nofollow">https://github.com/ido/macosx-bash-92-shellshock-patched</a><p>Binary releases are here: <a href="https://github.com/ido/macosx-bash-92-shellshock-patched/releases" rel="nofollow">https://github.com/ido/macosx-bash-92-shellshock-patched/rel...</a>
...including a .pkg file that can be installed with a double-click.<p>Instruction here:
<a href="https://github.com/ido/macosx-bash-92-shellshock-patched/blob/master/README.md" rel="nofollow">https://github.com/ido/macosx-bash-92-shellshock-patched/blo...</a><p>Pull requests are welcome, especially if you've modified Florian's patch to apply cleanly on 3.2, which is my next task.
Looks like it's in Ubuntu's build:<p><pre><code> $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.3 LTS
Release: 12.04
Codename: precise
$ dpkg -l bash | tail -1
ii bash 4.2-2ubuntu2.5 GNU Bourne Again SHell
$ foo() { echo foo; }
$ export -f foo
$ env | grep BASH_FUNC
BASH_FUNC_foo()=() { echo foo
</code></pre>
Is this a correct test?<p>Probably as of about 13:27 UTC yesterday, if I'm reading correctly here: <a href="https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/bash/precise-security/revision/64" rel="nofollow">https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise...</a>
Given that Florian is the guy making the decisions on the RHEL bash package updates, I suspect this patch is already in the latest RHEL/CentOS/Scientific Linux bash package (the one that came out early yesterday, soon after the patch was posted to the oss-sec list).<p>Edit: Confirmed in this bugzilla ticket comment <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c51" rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c51</a>
ASLR is another one of the nice things about dash compared to bash in Debian:<p><pre><code> $ hardening-check /bin/dash /bin/bash
/bin/dash:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes
/bin/bash:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no, not found!</code></pre>
As an alternative, make sure that /bin/sh is set to something other than bash. In Debian and Ubuntu it is already set to dash by default.<p>(There's no guarantee that dash doesn't have similar problems, but at least the surface area is smaller.)
I'm impressed by Florian. Not only is his turnaround time quick when people finds faults in what has been his baby for quite a few years now, he immediately recognizes real issues from the contant stream of non-issues being reported.<p>Everyone would think this is the way we would react, but in reality most people go out of their way to prove that these issues are not exploitable first. He spots them straight away with no pride to get in the way. Very professional.
here is someone's github that has some sample tests:<p><a href="https://github.com/hannob/bashcheck" rel="nofollow">https://github.com/hannob/bashcheck</a>
In case the site goes down or something, here's a check to see if you're vulnerable:<p><pre><code> foo='() { echo not patched; }' bash -c foo</code></pre>
Thank you God for Florian Weimer! Now that reason has prevailed over this insanity [1][2] I can sleep well again.<p>1. <a href="https://news.ycombinator.com/item?id=8368272" rel="nofollow">https://news.ycombinator.com/item?id=8368272</a>
2. <a href="https://news.ycombinator.com/item?id=8368676" rel="nofollow">https://news.ycombinator.com/item?id=8368676</a>
Does this unofficial patch work with a source code compile of bash 4.3 and patches 001 to 026? (Does this patch work on 4.3? Does this patch need to go on top of 025 and 026, or do I need to omit 025 and 026, or some other approach?) Thanks for advice -- much appreciated!
Must say I'm rather hesitant to recompile it myself with some code someone suggests will "harden" it somehow. If it's a good patch, why wouldn't it be included in the repositories? Or will it, but it probably takes a few days?<p>Edit: To clarify, after recompiling I would need to manually update it in the future (or switch back to the repositories once they include it). Applying this patch is not a apply-and-forget action. I don't really see the value of applying it myself, especially when I don't connect to public/company/school networks during the weekend.
I have a proposal. As an alternative to #!/bin/program I propose that<p><pre><code> #!program
</code></pre>
is executed by using a program at a known location (or perhaps by following a system defined internal `PATH`) with a system cleaned or defined environment (e.g. PATH=/bin:/usr/bin and a TERM matching [a-zA-Z0-9-]+<p>This would fix a lot of this shellshock nonsense and also be a better alternative to the #!/bin/env hack for finding programs at different locations on different systems.<p>Programs should use args for communicating.<p>Extended syntax for programs to declare that they really need certain environment variables:<p><pre><code> #!program env=WHITELIST OF ENV VARS ALLOWED</code></pre>