
Re: CVE-2014-6271 – remote code execution through bash - eddydkim
http://seclists.org/oss-sec/2014/q3/734
======
plq
And I'd like to thank Gentoo developers for the usual very fast response they
had towards this security advisory.

The moment I saw the news here, I ran to update my stuff -- the patch was
already there, marked stable in the official gentoo repositories.

My impression is that they're following very closely the progression of this
event and the relevant GLSA entries are being updated without any noticeable
delays.

Thanks for running the show guys, you're true professionals!

Here's the relevant Gentoo Linux Security Advisory (GLSA) link:
[http://www.gentoo.org/security/en/glsa/glsa-201409-10.xml](http://www.gentoo.org/security/en/glsa/glsa-201409-10.xml)

~~~
jo_
Same with Ubuntu, which I run on my servers. It was patched by the time I had
SSH'd in.

------
nextw33k
This issue is an awesome demonstration of how bad closed ecosystems are. The
open systems that are running on Linux (RedHat, ubuntu, etc) are patched and
updated.

However, OSX which is also affected is still waiting. If I owned an Apple
server I'd be screaming right now.

Embedded devices with closed eco systems are also stuffed (we've got to moved
to open router firmware like OpenWRT). Basically, you can carry on as normal
if you use open source the way it was intended.

~~~
Osmium
Devil's advocate: most OS X systems aren't running exposed services that could
be exploited, and if you were running an OS X server you can always re-compile
bash manually for something of this severity (and Homebrew/MacPorts make this
even easier).

That said, I do think it's ridiculous though how slow Apple is. It's
absolutely crazy. I can only hope that Heartbleed and now this are causing
some major internal reviews over there...

~~~
shabble
Even though I've got MacPorts bash installed, it lives in /opt/local/bin,
while the default one in /bin/{ba,}sh is the ancient apple 3.2 one.

[https://apple.stackexchange.com/questions/146849/#146851](https://apple.stackexchange.com/questions/146849/#146851)
has a simple enough step-by-step guide to patching & recompiling the system
version with the appropriate patches, if you've got XCode installed and are
comfortable with that sort of thing.

Agreed on the Apple security response time though. I reckon they have all
their best guys fighting the IOS jailbreakers :P

~~~
ergzay
You should jump to using Homebrew. It's superior in most ways. I'd used
MacPorts and Fink before Homebrew came about and I never much liked either.
Homebrew is as simple as it can be and is really good at detecting conflicts
which MacPorts and Fink were terrible at.

~~~
shabble
I've fought with both of them in the past, and ultimately went back to
MacPorts when I last reinstalled.

Homebrew was (at the time, maybe a year or so ago) missing a lot of things I
wanted to use, and some packages broke for no obvious reason.

I'm sure some of it was the result of my rather frankensteinien setup by that
point, but I have no real desire to reinstall things again until I have to.

MacPorts may be occasionally annoying, but at least it's usually in a way have
come to understand. :)

------
cft
This appears to be the same as [http://seclists.org/oss-
sec/2014/q3/att-690/eol-pushback.pat...](http://seclists.org/oss-
sec/2014/q3/att-690/eol-pushback.patch) at least for 4.3. But for 3.2
[http://seclists.org/oss-sec/2014/q3/att-690/eol-
pushback.pat...](http://seclists.org/oss-sec/2014/q3/att-690/eol-
pushback.patch) did not work, I had to download bash32-053.bin from Chet's
email.

Procedure for Ubuntu 8.04 and other installations where binaries are not
available (default 8.04 LTS server did not have m4 and bison dependencies),
assuming that 1st patch has already been applied per
[https://news.ycombinator.com/item?id=8364385](https://news.ycombinator.com/item?id=8364385)
:

    
    
      #Executing as root 
      #assume your sources are in /src:
      cd /src/
      echo "getting m4..."
      wget http://ftp.gnu.org/gnu/m4/m4-latest.tar.gz
      tar zxvf m4-latest.tar.gz 
      cd m4-1.4.17/
      ./configure && make && sudo make install
      cd /src/
      echo "getting bison..."
      wget http://ftp.gnu.org/gnu/bison/bison-3.0.tar.gz
      tar zxvf bison-3.0.tar.gz 
      cd bison-3.0
      ./configure && make && sudo make install
      echo "getting patch..."
      cd /src/
      #replace line below with wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-026 tomorrow
      wget http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.patch
      cd bash-4.3
      patch -p0 < ../eol-pushback.patch
      ./configure --bindir=/bin && make && sudo make install

------
rbobby
Not having worked with bash (et al) in ages I wonder whether allowing a
function definition (even without trailing commands) is not still hole? What
if you defined a function 'ls() { evil... }'... could a CGI script making a
call to 'ls' actually end up with the function instead of the real 'ls'?

~~~
stormbrew
I think the cases where it's still a hole are probably obscure and/or unlikely
in the wild, but I definitely think the response to this should have been to
disable the feature altogether. It's a terrible idea and I'm really curious if
anything actually uses it _and should be using it_.

~~~
philh
It's used to export functions from one instance of bash to a child. Do you
think that that's a terrible idea, or do you have a better idea of how to
implement it?

(The fix changes it so that exporting is done through specially named
variables. Instead of exporting `x='() { :; };`, it now exports
`BASH_FUNCTION_x()='() { :; };'`.)

~~~
stormbrew
Do any other shells do it? Afaik it's not part of the POSIX sh spec. So any
script that does it is going to be extremely dependent on bash in particular.

It would take actual use cases to convince me it's not a terrible idea. No
matter what it's a mechanism to throw arbitrary code into a script that has no
say in it. This is not the sort of thing you should do because it seems cool,
it should be the sort of thing you do because of a really compelling use case
that necessitates it. The fact that afaik no other shell has implemented this
behaviour since bash did (a couple of decades ago if I understand correctly?)
would rather suggest there is a lack of need for this.

------
mrmondo
Debian patched this 8 hours ago, Redhat issued a patch about 3 hours ago, I
believe Centos is still vulnerable, Ubuntu 14.10 isn't patched yet, Ubuntu
14.04 was patched about 3 hours ago.

~~~
psgbg
I'm using debian jessie (testing) i386, and I had to download bash myself
(from sid) because my up-to-date system was affected but the first patch was
available for sid (unstable) and wheezy (stable) and not in jessie.

So I don't know if every architecture, and version is updated with the same
speed.

~~~
mrmondo
Jessie isn't released / stable and doesn't receive security patches until it
is. It's called testing for a reason.

~~~
bigbugbag
debian testing do receive security patches, but it is not a priority so they
may not get there in a timely manner.

~~~
psgbg
Yeah. I'm aware that stable and old stable need to be patched first, I was
just surprised by how much time it took considering the kind of risk (and
being beaten by sid, the kid whom always breaks his toys).

------
xd
There seems to have been some confusion about the effect of this _feature_ on
PHP in previous threads on HN. If you are running mod_php you are unaffected
even if you use exec / system etc as the Apache PHP SAPI doesn't pass the
environment variables to the sub process.

However if you pass any user data (_POST, _GET, etc) into a system/exec etc
call that sets an environment variable then you would be vulnerable.

------
LeoPanthera
Available on Debian now.

[https://www.debian.org/security/2014/dsa-3035](https://www.debian.org/security/2014/dsa-3035)

------
Turbo_hedgehog
If you have some RHEL4 machines that you still haven't retired:

wget [https://oss.oracle.com/el4/SRPMS-
updates/bash-3.0-27.0.2.el4...](https://oss.oracle.com/el4/SRPMS-
updates/bash-3.0-27.0.2.el4.src.rpm)

rpm -ivh bash-3.0-27.0.2.el4.src.rpm

rpmbuild -ba /usr/src/redhat/SPECS/bash.spec

rpm -Uvh /usr/src/redhat/RPMS/x86_64/bash-3.0-27.0.2.x86_64.rpm

------
takefive1
I don't understand. I see that the fix causes bash to ignore function
definitions in the environment variable. But why should bash interpret the
variable's content in the first place, and not treat it as a string? I suppose
that someone can use eval if he really wants to execute it.

------
wincent
Amazon has released packages for their Linux AMIs that deal with both CVEs:
[https://alas.aws.amazon.com/ALAS-2014-419.html](https://alas.aws.amazon.com/ALAS-2014-419.html)

------
ck2
2nd CentOS update is out too
[https://news.ycombinator.com/item?id=8371164](https://news.ycombinator.com/item?id=8371164)

------
shawabawa3
My server actually got hacked through this. I patched the first vulnerability
quickly (arch linux, just did pacman -Sy bash). The second vulnerability was
published overnight, tried to ssh to my box to patch it in the morning: "enter
password:" \- uh oh, I use public key auth

My server runs a couple of wordpress sites and a rails app - not sure where
the vulnerability was exploited but be warned, looks like bots are already
crawling for it

~~~
Erwin
Huh. I thought the second issue did not have an exploit? That when set, all
would happen was that running "X Y" via a shell could instead run "Y > X " ?

~~~
scintill76
If the attacker can control a list of arguments and an env var value, you're
back to arbitrary command execution, albeit redirected somewhere. That sounds
suspiciously insecure even without bash vulnerabilities, though. Would be
interesting if GP knows what they used.

~~~
shawabawa3
I have no idea, I wasn't able to access any logs or anything.

It's possible they had already installed a backdoor using the first
vulnerability before I patched it, or perhaps something else entirely (though
that's a little too coincidental)

------
dperfect
Ubuntu: [http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2014/CVE-2014-7169.html)

RHEL:
[https://rhn.redhat.com/errata/RHSA-2014-1306.html](https://rhn.redhat.com/errata/RHSA-2014-1306.html)

CentOS update is available also - just not on some mirrors yet.

~~~
Thesaurus
I just patched my CentOS 6 server a few hours ago. Double check yum.

~~~
89vision
I patched mine about 10 hours ago. Is this one newer?

~~~
dperfect
Make sure you have bash-4.1.2-15.el6_5.2 instead of bash-4.1.2-15.el6_5.1
which was the initial patch.

------
andruby
I don't see the new update on Ubuntu 12.04. What version of bash contains the
complete fix? I'm still at 4.2.25(1)-release

~~~
isp
[http://www.ubuntu.com/usn/usn-2363-1/](http://www.ubuntu.com/usn/usn-2363-1/)
\- Ubuntu 12.04, bash 4.2-2ubuntu2.3.

------
brador
Is any fix going to be rolled out to older no longer supported versions of
Linux? I know they're out of support but I think this is a special case and
deserves the attention.

~~~
dspillett
Highly unlikely. Anyone still running an out-of-support instance who isn't
manually applying updates is already vulnerable to other unpatched issues
anyway, and those held back on old versions who _are_ manually applying
security updates (by compiling their own from upstream source and such) will
already be on the ball with this one.

------
Thesaurus
Very thankful this made it out today.

~~~
arecurrence
Agreed, kudos to everyone for the speedy response!

