
CVE-2014-6277 - chippy
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277
======
f-
This is an... odd submission. But I'm the guy who found this and the '78 one.
To cut to the chase, run this command from within bash:

_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-...](http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-
cracked.html)

~~~
ZoFreX
Am I right in thinking (based on that test above) that if a system has the
patch that adds the prefix/suffix, it's safe against this attack?

~~~
f-
Yup, unless you are doing something crazy.

------
jerf
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.

~~~
sillysaurus3
_if you have any interest in this matter but are only now hearing about it, it
is vital that you improve your connection to security news._

What would you suggest?

~~~
alec
My computer runs Debian, so I read debian-security-announce, which gets one
email per updated package. Sample of messages from this year:
[https://lists.debian.org/debian-security-
announce/2014/threa...](https://lists.debian.org/debian-security-
announce/2014/threads.html)

~~~
dchest
For Ubuntu:

[https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-
an...](https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce)

------
spacefight
Test code:

~$ bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null || echo vulnerable

~~~
ZoFreX
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.

------
orblivion
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.

------
dscrd
Seems to me that the only correct fix to Shellshock and this is to completely
remove bash from all systems.

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.)

~~~
dspillett
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).

------
willvarfar
Ancient news! It was found - and fixed - over a month ago now :)

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)](http://en.m.wikipedia.org/wiki/Shellshock_\(software_bug\))
has a list of the vulnerabilities found (so far).

~~~
f-
Obviously wasn't a month ago
([https://news.ycombinator.com/item?id=8432826](https://news.ycombinator.com/item?id=8432826)),
but yeah, it's not exactly fresh.

~~~
willvarfar
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?

------
super_mario
But BASH 4.3 is now at patch level 30? Isn't this old news now?

------
ck2
This is a month old?

Anyway, check with bashcheck
[https://github.com/hannob/bashcheck](https://github.com/hannob/bashcheck)

------
andrewstuart2
I might be reading it wrong, if they use base 0 for their months, but I think
this CVE was created a month ago today.

~~~
stevekemp
CVE identifiers are given ascending numbers, after the year-prefix.

You shouldn't try to guess the day/month from the number!

~~~
andrewstuart2
I'm actually referring to the "Date Entry Created" on the website, not
anything derived from the title or id.

