$ curl -s https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck | bash
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
bash: line 18: 14885 Segmentation fault: 11 bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs
Why does piping commands in to bash from the internet take on a magical security significance for people who run software they haven't audited literally all the time?
You don't see the difference between running an exploit to check if you're vulnerable to a security bug, and running software provided by your upstream distribution?
No, I don't see why people who run open source code from a variety of sources think that there's something magically insecure about downloading it and executing it using curl and bash.
This is a good question to think about, especially if it makes you consider more carefully about what software you run!
But there's a lot of spectrum between "i have audited this software" and "i'm just piping this random url off the web to my shell". Many software distribution mechanisms provide varying degrees of curation, reputation, accountability etc.
Also in this case the link was provided in a context that would select for people who are concerned about security updates (= looking after high value systems) and still somewhat naive about security practices, and could get run on systems that have strict rules about installing software on them.
Perhaps the parent commenter doesn't run software without audit. There's no reason to presume defeat -- It's wholly possible to run a modern system using only signed builds from trusted sources and compile-from-source from everything else.
Certainly, one can't audit every line, but just as certainly, one can establish a train of trusted sources and audit the rest (like this tiny snippet of bash, which is so utterly trivial to verify you might as well polish the habit on it).
I'm in the same boat. Though I see the argument that I'm running code I haven't audited all the time, there's something about a bash script in particular that gives me worry. I don't know how rational this is, but I feel like the author could switch the code momentarily to something exploitive, wait for N downloads, then switch it back. I'm not sure how you could gather evidence that this even happened, since the nature of `curl -s URL | bash` is so transient.
You're better off using any text editor - cat will display ANSI terminal codes unescaped in many situations, which can inhibit your ability to see code that might otherwise be hidden by # ^[[<wipe to beginning of line> or somesuch appended to a malicious bit.
Well since you went for a technical argument... if you really want to get technical.. it doesn't display anything and just sends the raw bytes to a stream.
It doesn't 'display' all bytes, because not all bytes are displayable. hexdump would do a better job there.
When you're looking at the page on Github, type "y" and it'll change the URL to the appropriate commit so you have a reasonable expectation that what you reviewed is what you're running:
We could at least reference a known good version by hash. This is at least a little more secure. But considering that Github could have been compromised by this bug, I would probably not pipe much from them until I know more about them not being compromised. Isn't running a jailed git server over ssh one of the great exploits of this bug?
Still potentially vulnerable to truncation, though I don't know that that could actually cause a problem with this payload. And of course, habits like this could quickly propagate infection if a trusted source is compromised (though there are certainly plenty of other habits that share that characteristic).
"Variable function parser inactive" -- interesting, did they apply the unofficial patch to namespace-prefix function definitions? This poster[0] seems to not have it, though. Who is right? The test at that github link seems a bit sketchy, by using a simple name like "a" instead of, say, __test_bashbug_a, and not checking the output very thoroughly. But it seems like it would fail the other way if there's a command named "a" in OS X's PATH...
It isn't unoffical anymore. For bash3.2, which seems to be what apple is distributing, that patch is ftp://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054
~$ echo $BASH_VERSION
4.3.25(1)-release
~$ curl -s https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck | bash
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
Not vulnerable to CVE-2014-6271 (original shellshock)
Vulnerable to CVE-2014-7169 (taviso bug)
bash: line 18: 1339 Segmentation fault: 11 bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)
And fwiw even before install new bash via homebrew I had also followed these instructions:
Also reproduced on 10.9.5 -- you would think that there's sometone at Apple looking at this forum and at hannob's bashcheck and that it would get tested. I guess there will be a 1.1 version of the update soon?
Is there a reason why this is not coming via the regular software update? I don't think a lot of people are watching Apple's support pages for updates.
It's still currently not showing up 16 hours later. I'm starting to wonder whether they're working on an updated version using one of the improved patches.
It's still not showing up for me. Checked on 3 separate Mavericks machines. So I downloaded the Software Update catalog (sucatalog) straight from Apple and did a case-insensitive grep for "bash" and there is absolutely nothing in there with that string. As far as I can tell, Apple has never offered this as anything but a standalone download that you need to fetch from them manually. Are we both talking about the same thing? (Apple Menu -> Software Updates)
Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between (released on the 26th I think?).
3-5 days is pretty decent considering that the DHCP stack on OS X isn't vulnerable and only customers that had enabled the apache2 instance and configured it with non-default mods were possibly affected.
More often than not Apple is removing GPL code from OS X altogether in the face of issues (example: samba is now replaced with 'smbx' in-house implementation).
I felt it was 50/50 that they'd update it vs. remove/disable it.
No way they'd remove it, there's probably hundreds of commercial software packages shipping with install scripts or even runtime scripts that depend on bash. That's a QA nightmare that would need to be planned across 1-2 annual major releases.
> Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between (released on the 26th I think?).
> 3-5 days is pretty decent ...
According to the timestamps on the GNU ftp site for bash, the first patch was released 2014-09-24 10:24 (unknown timezone).
Slackware had their first upgrade file-set out at Wed, 24 Sep 2014 16:37:00 -0700 (PDT) (for six different versions, in both i386 and x86_64 variants).
The second patch is timestamped 26-Sep-2014 17:02 on the GNU ftp site. Slackware's second upgrade file-set was out Thu, 25 Sep 2014 13:38:49 -0700 (PDT) (again with twelve different packages). [no idea why there is time travel here, likely the datestamp on the ftp site was subsequently updated for some reason]
The final patch is timestamped 27-Sep-2014 22:38 on the GNU site, and Slackware had out their third upgrade file-sets at Mon, 29 Sep 2014 12:33:36 -0700 (PDT).
Without knowing the FSF's timezone, we can only make estimates, but, for the first patch: same day, second patch: unknown, the time travel effect prevents making any estimates, third patch: about a day and a half.
And other distro's had patches out even earlier than Slackware, so, no, 3-5 days is _not_ pretty decent, it is actually downright poor.
Yeah, poor. How dare they go through their long established QA for something like this? How dare they do what literally every other company does.
Seriously, why do you think companies like Microsoft rather write workarounds to issues on their website instead of putting out a 2 line code fix for a given issue? Couldn't possibly be that their QA process would take so long that it is easier to just publish the work around, right?
Let me guess, Apple could not have done right by your standards. Had they just published a how-to in order to update bash by hand, you would bitch that this is insufficient. Had they published unstable versions of the fix (like your mentioned "other distros" did just so they could say they already have a fix) you would have piped up along the lines of "nice going publishing unstable fixes that probably introduce more leaks than they fix"
1) what difference would it have made, really, had apple distributed that first patch (that fixed one of 6 CVEs) instead of waiting for the second?
2) what attack vectors have you identified against an OSX system that exploit this vulnerability? (note that their dhclient imlpementation is not actually affected)
Even if you could find public servers running OS X that were exploitable, who would put effort into it? OS X also isn't glued together with scripts like a typical Linux system.
Kind of hard to remove Bash when it's the default shell and a great many scripts have been written targeting Bash features. Sure, there are other sh-compatible shells, but AFAIK they aren't 100% compatible with Bash.
Edit: If you disagree with me, please reply instead of downvoting.
How long ago did that happen? I know it uses Dash now but I'm not familiar with the shell history of Ubuntu.
Regardless, the difference is people who run Linux upgrade major versions intentionally (I assume the switch happened on a major version upgrade) and expect software packages to have to support their OS version. For example, the package manager keeps separate packages for each distribution.
OS X works differently. It's a customer OS, which people upgrade without reinstalling anything, and they expect their software to continue working. Furthermore, OS X software never targets specific OS versions, instead only targeting a minimum version, and software that works on one version of OS X is expected to work on the next version (any changes that break apps go through a deprecation process first, so the software has to be unmaintained for at least a major OS version before it will break).
Because of that, any software that relies on bash-specific functionality would break if bash were replaced, and it would generally be considered unacceptable.
What can be done is /bin/sh could be changed to another sh-compatible shell, but Bash would still have to be shipped on the system.
Ubuntu made the change for Ubuntu 6.10 (edgy), released in October 2006 (for those unfamiliar with the version scheme).
A slight correction to the poster before you: /bin/sh was linked to dash (making quite a few shellshock exploits fail on Ubuntu), while /bin/bash was the default user account shell... much as you've suggested!
On Yosemite:
$ /bin/sh --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin14)
Copyright (C) 2007 Free Software Foundation, Inc.
So yes, anything that naively creates subprocesses using /bin/sh -c is open to shellshock exploits on (unpatched) OS X. :-)
Actually, saying "please reply instead of downvoting" does seem to help. Of course, my goal isn't meaningless karma, it's to find out why people think my comment is worth downvoting. The few times I've edited a comment to say "please reply instead of downvoting", the downvotes stopped, and people start replying instead.
Sometimes, yes. But my actual goal is to encourage dissenters to reply, because I actually want to know why they disagree with me. The karma itself is entirely meaningless except in that it affects how many people end up reading the comment.
The guidelines were written in order to make HN a better place for the entire HN community. Your defense of "please reply instead of downvoting" only touches upon how it "seems to help" you.
Encouraging discussion helps everyone. That's what the comments are for. The guidelines have that line in them because people do not like reading complaints about being downvoted, and because those complaints are not productive conversation. Not because there is some underlying reason why drawing attention to the existence of comment moderation is somehow wrong.
>Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between
Apple didn't make the patch they just repackaged it. That's five days to write a dozen lines of script to update the shell. Every single GNU/Linux distro was patched the day of, get real.
>I felt it was 50/50 that they'd update it vs. remove/disable it.
Remove it for what ash/sh? Tim Cook doesn't know a megabit from a megabyte, let alone a shell. That pencil pusher doesn't care about his users, only the money. This was only patched for PR. Still no sight of it on the automatic updates list.
Probably only applies to released versions of OS X. Apple treats beta a bit differently than I think many expect. It is a bit closer to the old school definition.
Note that Apple has not provided updates for older systems. If you have an older system and wish to patch, I have been keeping my blog post [1] updated along with the canonical StackExchange answer [2].
Note that the patch from Apple allows bash functions to be escaped, albeit with a BASH_FUNC prefix - but you can get around this by using:
$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" bash -c ls
Hmph, the other thread fell off the front page, but:
There is a handy zsh script (zsh is in /bin on OSX by default) to get the Bash tarball from opensource.apple.com, apply patches 52, 53, and 54 from ftp.gnu.org, build it, and then prompt to replace /bin/bash and /bin/sh. Xcode is required, and you have to run "sudo xcodebuild" once to accept the EULA.
Disconcertingly, this doesn't show up in Software Update on my machine running 10.10, but that may be because I'm on the beta. Is this being pushed to the App Store/Software Update for OS' < 10.10?
(For those wondering, the 10.9 installer does not run on 10.10)
Are you running a public-facing Apache server on the beta?
I wouldn't call it disconcerting that they're focusing their resources on released versions of OS X. I'd rather they cover the other CVEs sooner and ship 10.10.0 with no issues[1] when it's done than divert engineering resources to ship a patch for Yosemite.
[1] bash-related issues, at least. Apple's .0 track record speaks for itself.
(master) $ echo $BASH_VERSION
4.3.27(1)-release
(master) $ ./bashcheck
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: line 18: 7675 Segmentation fault: 11 bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs
It seems as though there is no patch that fixes CVE-2014-7186 yet?
I may be wrong here, but I'm pretty sure as long as you aren't running any network services, you are probably ok.
This is a big deal because it's remotely exploitable. But it's only exploitable remotely if you are running a network daemon that somehow invokes bash and sets environment variables without sanitization. Web sharing, SSH in some instances, a few MTAs.
The average user PROBABLY isn't running a daemon that is vulnerable. Though in some cases, you may be and not know it (like if you had turned on Web Sharing at some point)
All of this is not to say that if you can apply the patch, do it.
Yes and no. Bash gets used in many, often invisible, ways. Even a piece of compromised software run locally, or a web service accessing local data may present a problem. Admittedly this is a remote chance (and not in the wild afaik), but better safe than sorry. Patch took all of a minute to install. Let's hope it's actually a complete fix.
Yeah :/ That's the reason a lot of publications are calling this worse than heartbleed. Another problem is that it's up to individual users to fix - not just the people running servers.
That could be fixed by this patch[0], which is not official and might break backward compatibility.
If you're facing an attacker with arbitrary control of both name and value of environment variables, and shell scripts that don't sanitize, you've got worse problems IMO.
Still, some Linux distributions are applying this unofficial patch, to only parse function definitions in prefixed environment variables to mitigate the threats.
As others have mentioned, OSX is immune from the DHCP side.
Even then, at least the exploit for DHCP I saw manifests on the SERVER, not the client. When you are in a coffee shop, you are the client not the server. That means you would be the one to exploit the coffee shop, not the other way around.
No, the DHCP exploit was not on the server. It showed a sample payload a malicious DHCP could send to a client to achieve RCE. Also apparently some networks allow other clients to send DHCP commands so even if you trust the DHCP server it doesn't necessarily mean you are safe.
I don't use Linux, so I can't say for sure, but I've read that Linux DHCP cilents often call out to bash, so you should definitely upgrade if you ever connect your computer to untrusted networks (which you almost certainly do if it's a laptop and you're not paranoid)
You should upgrade regardless, though, since bash is so ubiquitous that it's hard to be sure you're not vulnerable in some esoteric way.
Most likely nothing. You probably aren't running a web server that shells out to do CGI or something else. Macs don't use shell to do their network config. Those are the 2 biggies in the Linux world right now.
Basically to be vulnerable requires 2 components:
1. You have to be able to get some remote user specified stuff into a environment variable.
2. You have to invoke /bin/sh (calls to system(3)[1] do this, as well as actual shell scripts).
If you just have a non-server mac, there's no huge rush--no one has identified an actual stock service/daemon that is susceptible to the vulnerability.
With Apple stuff it seems like it's best to stay within 2 revisions of the latest OS, especially since they've moved to shorter release cycles (yearly).
Thanks, I'll work out what to do instead, then. Problem is she won't sit through lessons about what multi-touch gestures to use to find that chrome popup window that disappeared or whatever, I would be loath to help her navigate something like the UI updates in Lion, let alone beyond.
If only Alt+Tab worked on windows rather than apps, like in MS OSs, or even if there was a taskbar-style way to switch windows, she'd have so many fewer problems...
> [..] multi-touch gestures to use to find that chrome popup window that disappeared [..]
This may not help for your case, but it may interest keyboard shortcut junkies.
When I was getting used to the "interesting" way OS X handles CMD+TAB versus Windows' ALT+TAB, I was also frustrated at the app-vs-window issue.
I eventually figured out this workaround, which sounds complicated but is now muscle memory:
1. Hold CMD. (Don't let go until I say so.)
2. Press TAB once.
3. Tap the arrow keys (LEFT/RIGHT) to go to the correct application, e.g. Chrome.
4. When you have the correct application selected, press DOWN. (You can release CMD now.)
5. This will display all of the open windows for this application (same as "4 finger swipe down" gesture). You can use the arrow keys to navigate this. An extremely subtle blue halo is displayed around the selected window. Press RETURN to select.
Interestingly, I'm using GNOME on Linux partly because they use the same Alt-Tab behavior as OS X. As a power user with many windows per app the default Windows behavior is less efficient
I'm pretty sure they're not doing security updates in general for Snow Leopard anymore, so if you're concerned about security then that should be a much more worrisome to you than the fact that there's no bash fix.
Apparently you must be punished for daring to let your partner use something that's still perfectly functional for many uses, when Apple has something newer!
Maybe they're saying you should upgrade for security reasons, but it'd be nice if they actually said it. Seriously, I'm failing to understand the amount of downvote-hate being focused on you right now, in every comment you gave in this thread. Sorry.
Here’s for the crazy ones, the misfits, the trouble makers, the round pegs in the square holes. The ones who see things differently... and are still running Snow Leopard.
sadly this will update bash on 10.9.5 only. Im on 10.9.3 because the last mac I updated to that version caused it to kernel panic whenever I connected an external monitor.
OS X Mavericks: GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
OS X Mountain Lion: GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin12)
OS X Lion: GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin11)
