5 ms·
Bash bug: apply the unofficial patch now (CVE-2014-6277)
- cbd1984 12y agoIn 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 12y agoIf 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.)
- DrJ 12y agohere is someone's github that has some sample tests: https://github.com/hannob/bashcheck https://github.com/hannob/bashcheck
- jewel 12y agoAs 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 12y agoEhh... Plenty of shell scripts explicitly specify bash in order to use its extended features, so this may or may not protect you.
- takeda 12y agoThe 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.
- plorg 12y agoIn 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.
- deleted 12y ago[deleted]
- nitrogen 12y agoThe 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
- dfc 12y agoUnfortunately 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 12y agoWhat 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.
- davidgerard 12y agoTen 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.
- SwellJoe 12y agoGiven 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
- idorosen 12y agoFor 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/releases 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/blob/master/README.md 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.
- terinjokes 12y agoFor the record, it applies cleanly on top of the other two patches.
- jph 12y agoDoes 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- 12y agoIt should work on top of the original patch with 4.3. Don't omit 025.
- lucb1e 12y agoMust 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 12y agoFlorian (the author of the new patch) is from Redhat - not just a random internet stranger.
- lucb1e 12y agoSo then surely Mint's (or Ubuntu's) team will include it in the repositories?
- scintill76 12y agoI think they have: https://news.ycombinator.com/item?id=8378320 https://news.ycombinator.com/item?id=8378320 It'd be good to have confirmation that my little test is correct, though.
- _ak 12y agoAFAIK, Florian Weimer is also in the Debian security team.
- rurban 12y agoNot that this a good qualification. Being the redhat bash maintainer and member of the redhat security team is one.
- thibaut_barrere 12y agoSee https://news.ycombinator.com/item?id=8378203 https://news.ycombinator.com/item?id=8378203
- deleted 12y ago[deleted]
- scintill76 12y agoLooks 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/bash/precise-security/revision/64 https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise...
- dashesyan 12y agoIt looks like you're right. Thanks!
- f- 12y agoYup, 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 12y agoAh, much simpler test. Thanks!
- dfc 12y agoASLR 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 12y agoGentoo 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
- bjornsing 12y agoThank 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
- emmelaich 12y agoI 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
- dfc 12y ago$ env -i WLIST=$WLIST WLIST2=$WLIST2 command
- emmelaich 12y agoI'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.
- f- 12y agoUsing 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.
- jldugger 12y agoThis would have done nothing to prevent shellshock; placing user submitted data placed in ENVVARs is 'working as intended' for CGI, DCHPCP, etc.
- 12y ago
- xorcist 12y agoI'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 12y agoWell, 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 12y agoI 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.
- erso 12y agoFor 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