
Bash bug: apply the unofficial patch now (CVE-2014-6277) - stakent
http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html
======
idorosen
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](https://github.com/ido/macosx-bash-92-shellshock-patched)

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

Instruction here: [https://github.com/ido/macosx-bash-92-shellshock-
patched/blo...](https://github.com/ido/macosx-bash-92-shellshock-
patched/blob/master/README.md)

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

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

------
scintill76
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...](https://bazaar.launchpad.net/~ubuntu-
branches/ubuntu/precise/bash/precise-security/revision/64)

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

~~~
scintill76
Ah, much simpler test. Thanks!

------
SwellJoe
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](https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c51)

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

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

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

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

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

~~~
dfc
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](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=762923)

~~~
emmelaich

        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.

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

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

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

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

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

~~~
3ifbyw
Exactly an hour, in fact:
[https://github.com/wting/hackernews/blob/master/news.arc#L11...](https://github.com/wting/hackernews/blob/master/news.arc#L1180)

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

[https://github.com/hannob/bashcheck](https://github.com/hannob/bashcheck)

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

~~~
frankzinger

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

------
erso
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](https://github.com/Homebrew/homebrew/pull/32753)

------
bjornsing
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](https://news.ycombinator.com/item?id=8368272)
2\.
[https://news.ycombinator.com/item?id=8368676](https://news.ycombinator.com/item?id=8368676)

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

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

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

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

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

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

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

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

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

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

