Bash bug: apply the unofficial patch now (CVE-2014-6277) | Hacker News Reader

Bash bug: apply the unofficial patch now (CVE-2014-6277)

lcamtuf.blogspot.com

124 pointsstakent45 comments

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and the CVE-2014-7169 patch. I will be applying Florian's patch once it or a similar patch come out for 3.2.

Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched

Binary releases are here: https://github.com/ido/macosx-bash-92-shellshock-patched/rel... ...including a .pkg file that can be installed with a double-click.

Instruction here: https://github.com/ido/macosx-bash-92-shellshock-patched/blo...

Pull requests are welcome, especially if you've modified Florian's patch to apply cleanly on 3.2, which is my next task.

For the record, it applies cleanly on top of the other two patches.

Looks like it's in Ubuntu's build:

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:	Ubuntu
  Description:	Ubuntu 12.04.3 LTS
  Release:	12.04
  Codename:	precise
  $ dpkg -l bash | tail -1
  ii  bash                              4.2-2ubuntu2.5               GNU Bourne Again SHell
  $ foo() { echo foo; }
  $ export -f foo
  $ env | grep BASH_FUNC
  BASH_FUNC_foo()=() {  echo foo

Is this a correct test?

Probably as of about 13:27 UTC yesterday, if I'm reading correctly here: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise...

It looks like you're right. Thanks!

Yup, as of yesterday, they are shipping the unofficial patch. I added a simple command to test if you're patched at the bottom of the blog post.

Ah, much simpler test. Thanks!

Given that Florian is the guy making the decisions on the RHEL bash package updates, I suspect this patch is already in the latest RHEL/CentOS/Scientific Linux bash package (the one that came out early yesterday, soon after the patch was posted to the oss-sec list).

Edit: Confirmed in this bugzilla ticket comment https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c51

ASLR is another one of the nice things about dash compared to bash in Debian:

  $ hardening-check  /bin/dash /bin/bash
  /bin/dash:
   Position Independent Executable: yes
   Stack protected: yes
   Fortify Source functions: yes (some protected functions found)
   Read-only relocations: yes
   Immediate binding: yes
  /bin/bash:
   Position Independent Executable: no, normal executable!
   Stack protected: yes
   Fortify Source functions: yes (some protected functions found)
   Read-only relocations: yes
   Immediate binding: no, not found!

Gentoo Hardened for the win:

  zx2c4@krantz ~ $ hardening-check /bin/bash
  /bin/bash:
   Position Independent Executable: yes
   Stack protected: yes
   Fortify Source functions: yes
   Read-only relocations: yes
   Immediate binding: yes

As an alternative, make sure that /bin/sh is set to something other than bash. In Debian and Ubuntu it is already set to dash by default.

(There's no guarantee that dash doesn't have similar problems, but at least the surface area is smaller.)

Ehh... Plenty of shell scripts explicitly specify bash in order to use its extended features, so this may or may not protect you.

The problem really is with calls like system("command") which ultimately translate to: '/bin/sh -c "command"'.

I'm quite sure that's what happens in DHCP case.

In most cases dhclient scripts are written in bash. In any case they are executed by dhclient-script, the shebang of which - at least in Ubuntu - calls for it to be executed by /bin/bash for the specific reason that the maintainer did not want to rewrite out bash-isms when the default system shell was switched to dash.

The problem really is with calls like system("command") which ultimately translate to: '/bin/sh -c "command"'.

That is definitely a problem, but it's not the only problem. Try running this from /usr/bin (it returns lots of results on Linux Mint, Ubuntu, or Debian):

    grep -nR '#!.*bash' * | grep :1:

Just as a random example, on an unpatched Debian wheezy system /usr/bin/fakeroot is vulnerable:

    $ x='() { :;}; echo vulnerable' /usr/bin/fakeroot
    vulnerable

Unfortunately this is not the case in debian. There is an open bug to replace bash with dash. There do not seem to be many bashisms in the actual script. Sadly a member of the security team did not seem to be persuaded by the utility of the switch:

  > Given the many eyes now turning towards findings bugs in bash
  > and  building exploits  with them  it might  be safer  to fix
  > those bashisms and switch dhclient-script over to #!/bin/sh.
  >
  > What do you think?

  Actually, if you go that road,  you would need to drop anything
  ever calling  python, perl,  ruby or whatever  language somehow
  remotely. Some scripts might have good reasons to uses bash and
  bashisms (I'm not saying that's the case here, but still).

  What I  find more concerning  is to pass  unchecked environment
  variable directly from remote (or any input, actually).

[1]: dhclient-script uses bash, allowing remote bash exploits / https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762923

    What I  find more concerning  is to pass unchecked
    environment variable directly from remote (or any input, actually).

You can understand the opinion to an extent because it would require the every program to know in every case what variables are needed and what they're supposed to look like.

sudo does this to a small extent; it wipes function env vars.

In the rare system/popen my programs do I explicitly give the entire env - just PATH=/bin:/usr/bin; sometimes I give an empty env.

For something like a dhcp client it is obviously bad. The responsibility there is to whatever invokes it.

My complaint with the response was the "if you go down that road" response. The bug submitter was not suggesting dropping shell scripts, it was a request to remove the bashisms from dhclient so that it could work with dash.

It is not like there is an alternative python/ruby implementation that is "more robust against software failures" and has DEB_HARDENING turned on. If there was I would totally support going down the road of "making small changes to programs that process data from anyone on the network" so they could run on HardPython.

If there was something like HardPython alternative that was "more robust to software failures" with st

Ten years later, there are still bashisms and explicit calls to /bin/bash lurking in Debian/Ubuntu (e.g. dhclient). So no, you gotta update bash.

I'm impressed by Florian. Not only is his turnaround time quick when people finds faults in what has been his baby for quite a few years now, he immediately recognizes real issues from the contant stream of non-issues being reported.

Everyone would think this is the way we would react, but in reality most people go out of their way to prove that these issues are not exploitable first. He spots them straight away with no pride to get in the way. Very professional.

Well, if somebody like lcamtuf tells me there's a vulnerability in my code, I would tend to doubt myself first :)

But I do agree, impressive and professional.

I meant to write Chet above of course. Sorry about that. Sometimes there is an edit-link I can click on to fix my mistakes and sometimes it's gone, I never understood why.

The edit link goes away after an hour or so of posting the comment.

Exactly an hour, in fact: https://github.com/wting/hackernews/blob/master/news.arc#L11...

here is someone's github that has some sample tests:

https://github.com/hannob/bashcheck

In case the site goes down or something, here's a check to see if you're vulnerable:

    foo='() { echo not patched; }' bash -c foo

    If the command shows "not patched", you don't
    have the patch. If it shows "command not found",
    you're good.

(FYI; I thought "command not found" meant that the test code was malformed.)

For homebrew:

    cd $(brew --repository)
    git remote add krishicks git@github.com:krishicks/homebrew.git
    git fetch krishicks bash
    git checkout krishicks/bash
    brew upgrade bash

I've opened a PR: https://github.com/Homebrew/homebrew/pull/32753

Thank you God for Florian Weimer! Now that reason has prevailed over this insanity [1][2] I can sleep well again.

1. https://news.ycombinator.com/item?id=8368272 2. https://news.ycombinator.com/item?id=8368676

Does this unofficial patch work with a source code compile of bash 4.3 and patches 001 to 026? (Does this patch work on 4.3? Does this patch need to go on top of 025 and 026, or do I need to omit 025 and 026, or some other approach?) Thanks for advice -- much appreciated!

It should work on top of the original patch with 4.3. Don't omit 025.

Must say I'm rather hesitant to recompile it myself with some code someone suggests will "harden" it somehow. If it's a good patch, why wouldn't it be included in the repositories? Or will it, but it probably takes a few days?

Edit: To clarify, after recompiling I would need to manually update it in the future (or switch back to the repositories once they include it). Applying this patch is not a apply-and-forget action. I don't really see the value of applying it myself, especially when I don't connect to public/company/school networks during the weekend.

Florian (the author of the new patch) is from Redhat - not just a random internet stranger.

So then surely Mint's (or Ubuntu's) team will include it in the repositories?

I think they have: https://news.ycombinator.com/item?id=8378320 It'd be good to have confirmation that my little test is correct, though.

AFAIK, Florian Weimer is also in the Debian security team.

Not that this a good qualification. Being the redhat bash maintainer and member of the redhat security team is one.

See https://news.ycombinator.com/item?id=8378203

So you're saying it'll be included, but it might take a few days and it's better to get the update right now?

Yes, do an update first to see whether it fixes it. Vendors and mirror sites are getting it out fast.

As well as the test noted here you can check the the changelog in rpm. (sorry don't know how to do it for debian osx ...)

    rpm -q --changelog bash

I have a proposal. As an alternative to #!/bin/program I propose that

    #!program

is executed by using a program at a known location (or perhaps by following a system defined internal `PATH`) with a system cleaned or defined environment (e.g. PATH=/bin:/usr/bin and a TERM matching [a-zA-Z0-9-]+

This would fix a lot of this shellshock nonsense and also be a better alternative to the #!/bin/env hack for finding programs at different locations on different systems.

Programs should use args for communicating.

Extended syntax for programs to declare that they really need certain environment variables:

    #!program env=WHITELIST OF ENV VARS ALLOWED

  $ env -i WLIST=$WLIST WLIST2=$WLIST2 command

I've been meaning to ask ... why have all the examples for shellshock used `env`? Without even an -i?

My guess is that the unadorned `ONESHOTENVVAR=1 someprogram` is a little obscure to some. As to the lack of -i; it almost certainly necessary makes no difference to the result.

Using env may be slightly more portable if you're using an exotic login shell that doesn't support the "FOO=1 program" syntax - say, tcsh.

But for most part, it's probably just people copying-and-pasting stuff without really figuring it out what it does. For example, compare "exploit #1" and the supposedly different "exploit #3" on shellshocker.net.

This would have done nothing to prevent shellshock; placing user submitted data placed in ENVVARs is 'working as intended' for CGI, DCHPCP, etc.

Yes, with the whitelist (any whitelist) it would not have stopped shellshock. But having a whitelist would at least make them think about what they use which might help prevent other vulnerabilities.

I could propose that the whitelist be parsed before handing to any program. But that would be putting a potentially expensive and difficult job in a higher privileged place.

I think the rest is worth considering though.

Reply on news.ycombinator.com