CVE-2014-6277
cve.mitre.org
cve.mitre.org
_x='() { echo vulnerable; }' bash -c '_x 2>/dev/null || echo not vulnerable'
If it says "vulnerable", you need to:
1) Immediately update bash to the latest version provided by your distro, or manually recompile with all the applicable patches from ftp://ftp.gnu.org/gnu/bash/ (look at bash-*-patches for your version).
2) Make sure that you have a more reliable way to stay in the loop on important security updates in the future, since most major vulns don't make it to HN - and this one is more than a week old.
...
If you're interested in what "CVE-2014-6277" actually is, or what that test does, check out my recent blog posts, probably starting with:
http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-...
What would you suggest?
Your bash is safe if it has a patch level equivalent to bash 4.3-027 (released 27-Sep-2014 22:38). Several distros had the equivalent patch by Florian Weimer already a day earlier. The later bash patches fixed the underlying bugs, but that patch removed the attack surface (but introduced a backwards compatibility problem for the very, very few programs (I don't know of any) that actually create shell functions to be inherited by bash).
http://unix.stackexchange.com/questions/158767/which-debian-...
It looks like Debian may have applied something to make the attack not exploitable, even though it still segfaults. Seems weird to me, but it's the best explanation I have.
As I explained above, the patch for CVE-7169 by Florian Weimer made bash invulnerable to code injection by arbitrary environment variables. The underlying bugs CVE-6277 and CVE-6278 therefore have no known attack vector from outside bash, though they can still be triggered from a shell script or the command line if they are not patched. Theoretically, they could become part of a different attack, so it's wise to patch them, but there's no hurry, since as long as you or Debian have applied the abovementioned patch for CVE-7169, it means there's currently no publicly-known exploit.
Also, Debian uses dash as its version of sh, so the problem can only occur if bash is called explicitly.
Interestingly, I see many references to 6271 and 7169 but nothing for 6277. Can anyone break this down better?
~$ bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null || echo vulnerable
Edit: Using the other test further up thread (which does actually make use of environment variables), my system says "not vulnerable". I think this test is not perfect.
Id the seg fault a red herring, or does it suggest I hve a verison of bash that attempts to filter out the problem?
I have answers to some of the above questions, but I'm restating them rhetorically to make the point that this stuff should be a lot more straightforward. I think this info should be available in a much more straightforward manner by the distros.
I'm not sure what to replace it with. rc perhaps?
(Yes, I know that almost every distribution depends heavily on bash for all kinds of things. It won't be trivial.)
It deliberately doesn't offer any extensions (including "bashisms" that are used unwittingly in many scripts you'll find out there) or features for making interactive use more pleasant, so it probably isn't what you want for your login shell, but using it as your default /bin/sh significantly reduces your exposure to the recently discovered (and patched) vulnerabilities in bash (and you'll have slightly faster boot and CGI invocation times too).
This was one of a spate of bugs found when people started poking Bash's parsing.
This particular bug was found by Michał Zalewski.
http://en.m.wikipedia.org/wiki/Shellshock_(software_bug) has a list of the vulnerabilities found (so far).
I certainly recalled it from back in shellshock days, but was mislead by the filing date on the advisory. Why on earth do they have wrong dates on things?
Anyway, check with bashcheck https://github.com/hannob/bashcheck
You shouldn't try to guess the day/month from the number!