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:
I'm double-mistaken. This is a month old. So, back to the original message. If you are just hearing about it, you really need to update your security news feeds, if you are responsible for any systems that have bash on them.
Your distro should be up to date already. They have been pretty quick on the uptake, many even quicker than the bash maintainer himself.
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).
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.
You are confused. You say that you didn't get any updates on Debian, yet you say that it looks like Debian may have applied something.
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.
Batches of CVE numbers get pre-allocated to major players well ahead of any actual vulns being found, so that there is no need to individually request IDs from a central authority for, say, every single browser bug.
That happened here, the vuln itself is... um, around two weeks old.
Seems like an anachronism that might be worth updating. Surely just give the CVE number when the vuln gets submitted, eg as a date+index. Is it difficult to issue IDs on demand for some reason? If multiple bugs are submitted together then whatever app that doles out the CVE numbers could give them the same date and different indexes to indicate this. Co-terminus bugs could be treated as linked.
I think 27 is first one without any of these issues. That's what "pkg audit" on my freebsd box is telling me at least. Currently on 27 and it doesn't show any issues. They could just be out of date though.
Patches 28-30 fixed underlying bugs, but 27 closed the loophole that made them accessible from the outside. So if you have 27 but not the later ones, you are safe from any currently known attack method from "outside" bash; you can still trigger unexpected code execution from the command line or a shell script, but this cannot be done remotely anymore. Theoretically, these bugs could be used as part of another attack, so it's wise but not urgent to patch them anyway.
Why does this mean I'm vulnerable? To what attack, exactly? My bash is already patched to not execute code in environment variables, so how is an attacker going to get the above exploit to be running in my shell?
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.
I just want to take the opportunity to state that, being a Linux user but not any sort of serious sysadmin, navigating all this information is very confusing. This is an old bug report? And yet Ubuntu released a patch this morning? Why didn't I get a patch on Debian? I can see on ubuntu's bash page on launchpad what bugs were fixed in the most recent version, but which vulnerabilities were fixed in previous versions? Exactly what is a given distro still vulnerable to, right now? Looking at the dates posted, why does it look like there is such a long timeline between finding the bug, fixing it, and having it show up in the distro?
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.
Debian have moved over to using dash as the default system shell, as it is leaner and more efficient while being fully posix compliant and so forth.
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).
It's fine to have bash on your system as your interactive shell, if that's your preference. The problems occur when you have /bin/sh symlinked to bash. "Bash is for people, not for scripts" :)
Thx for the correction and nice work finding it :)
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?
_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-...