Bash bug: apply the unofficial patch now (CVE-2014-6277)(lcamtuf.blogspot.com)
lcamtuf.blogspot.com
Bash bug: apply the unofficial patch now (CVE-2014-6277)
http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html
49 comments
For the record, it applies cleanly on top of the other two patches.
Looks like it's in Ubuntu's build:
Probably as of about 13:27 UTC yesterday, if I'm reading correctly here: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise...
$ 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...
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!
It looks like you're right. 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
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: yesAs 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.)
(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.
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):
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
vulnerableUnfortunately 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
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
[deleted]
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.
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.
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.
[deleted]
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
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 [email protected]: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/32753Thank 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
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.
[deleted]
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.
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.
[deleted]
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 ...)
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 bashSo you're saying it'll be included, but it might take a few days and it's better to get the update right now?
I have a proposal. As an alternative to #!/bin/program I propose that
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
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 ALLOWEDThis 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.
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.
$ env -i WLIST=$WLIST WLIST2=$WLIST2 commandI'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.
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.
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.
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.