Re: CVE-2014-6271 – remote code execution through bash | Hacker News Reader

Re: CVE-2014-6271 – remote code execution through bash

seclists.org

108 pointseddydkim51 comments

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

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

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.

I don't want to defend Apple too much – at various points I spent many months hoping nobody else discovered a MITM exploit before they shipped the next OS release – but this is a near-complete non-issue for an OS X desktop user and even servers have fairly limited exposure.

If you want to beat Apple up, a much better case was goto fail where they left all of the Mac users hanging for a long period of time after shipping the iOS patch and disclosing the vulnerability.

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

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

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.

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

How is OSX a closed system in this particular case? You can easily compile bash, with patches, and replace the system binary -- using the same code that's used to build those Debian/Redhat/whatever binary. Its all the same gnu code.

What about all those EOLed distros that don't see most security updates? Being "Open" is a non-issue here.

There are many ways to argue this way or that way.

I could argue, that there is a bug for over 20 years in open source and nobody discovered it? WTF? So Windows is better, because it does not has this bug in the first place?

There is no right or wrong. Open Source is not better and not worse. Everything has its place and its purpose.

Regarding those embedded device I can say, they don't use BASH. Because of size constraints they all use Busybox, which does not have this problem, like all those other Shells.

This appears to be the same as http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.pat... at least for 4.3. But for 3.2 http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.pat... 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 :

  #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

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'?

You can't control the name of the function - that's dictated by the name of the environment variable. The feature at fault is activated by the presence of "(){" at the start of the environment variable value.

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.

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()='() { :; };'`.)

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.

Yes, but if you can control enviroment variable names then you can also set LD_PRELOAD and a whole load of other nasty enviroment variables.

...although some programs blacklist unsafe environment variable names. They all should be updated to also blacklist bash function values.

fortunately, sudoers(5) (et al.) whitelist certain variables.

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.

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.

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

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

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

I did 'yum update bash' on my Centos 5.8 Linode a couple of hours ago, and it updated to 3.2-33 and is apparently no longer vulnerable, according to the one-line test I have been using:

  X="() { :;} ; echo busted" /bin/sh -c "echo stuff"

That test doesn't detect the vulnerability - needs to mention /bin/bash not /bin/sh

Well, maybe you should look at your /bin/sh

ls -l /bin/sh

lrwxrwxrwx 1 root root 4 Sep 24 08:07 /bin/sh -> bash

I think /bin/sh is /bin/bash on CentOS and RedHat, but Debian, Ubuntu and probably other distros use dash as /bin/sh instead which was never vulnerable.

CentOS released a patched bash package around 2AM GMT, something like an hour after RedHat.

Looks like 14.10 is patched now

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.

Available on Debian now.

https://www.debian.org/security/2014/dsa-3035

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

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

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.

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

2nd CentOS update is out too https://news.ycombinator.com/item?id=8371164

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

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 " ?

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.

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)

Ubuntu: http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...

RHEL: https://rhn.redhat.com/errata/RHSA-2014-1306.html

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

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

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

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.

Yup.

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

http://www.ubuntu.com/usn/usn-2363-1/ - Ubuntu 12.04, bash 4.2-2ubuntu2.3.

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.

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.

Very thankful this made it out today.

Agreed, kudos to everyone for the speedy response!

Reply on news.ycombinator.com