OS X Bash Update 1.0 | Hacker News Reader

OS X Bash Update 1.0

support.apple.com

247 points0x0155 comments

With the update installed:

  $ 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

I just reproduced this on 10.9.5 as well.

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?

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

https://news.ycombinator.com/item?id=8385819

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

They applied the unofficial one. The official one uses a different suffix.

Cool, thanks for the pointer.

After testing it by doing:

  $ foo() { echo foo; }
  $ foo
  foo
  $ export -f foo

I got this variable:

  __BASH_FUNC<foo>()=() {  echo foo
  }

How can I patch the bugs that are listed as still vulnerable?

brew install bash

This still keeps the system version around at /bin/bash

Still showing as vulnerable even after that:

    ~$ 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:

http://apple.stackexchange.com/questions/146849/how-do-i-rec...

Don't forget to change your PATH so brew-installed things come before other things.

Brew installs bash at `/usr/local/bin/`.

That doesn't solve the problem of scripts that begin with #!/bin/bash

I'm sorry for being snarky, but something seems funny to me about piping something straight from github through bash to check for a security flaw.

(Oh actually, you could probably do it pretty safely with a guest account.)

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?

In the case of a network interruption, a command could become truncated with potentially destructive results.

That would result in a broken pipe and the command being aborted. We're not dumping raw datagrams here...

https://news.ycombinator.com/item?id=8385374

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.

I'd rather take an extra few seconds to do:

    $ curl https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck > bashcheck.sh
    $ cat bashcheck.sh # nothing fishy
    $ chmod +x bashcheck.sh && ./bashcheck.sh

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.

“cat” will display all bytes unescaped – that’s its job. The correct command in this case would be “less” (or any other pager, or possibly editor).

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.

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?

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:

https://raw.githubusercontent.com/hannob/bashcheck/9ee8db0bf...

(This assumes Github hasn't been rooted and you don't have a MITM with access to a trusted CA but … almost everyone is screwed at that point)

It's https, so no worries.

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

From Yosemite GM candidate:

Not vulnerable to CVE-2014-6271 (original shellshock)

Not vulnerable to CVE-2014-7169 (taviso bug)

Not 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

Also for 10.8: http://support.apple.com/kb/DL1768

And for 10.7: http://support.apple.com/kb/DL1767

Edit: Further information from the announcement is available here: http://lists.apple.com/archives/security-announce/2014/Sep/m...

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.

This information was released in an Apple mailing list: http://lists.apple.com/archives/security-announce/2014/Sep/m...

The direct download pages are published first. It should be showing up on the update servers shortly.

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 also seems positively weird that Apple's support pages and this security update aren't delivered via https.

The update package itself is signed.

It is coming with the regular update for me.

Yea, it took a few hours to show up there. Wasn't showing up when the patch was released.

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)

Do note:

This addresses CVE-2014-6271 and CVE-2014-7169 only. There are currently 6 CVEs listed on the Wikipedia page (not sure which are accurate): http://en.wikipedia.org/wiki/Shellshock_%28software_bug%29#S...

Some protection is better than none and I'm glad to see Apple rapidly responding. But this doesn't fix all the issues known to exist currently.

  > I'm glad to see Apple rapidly responding

It seems we have different expectations concerning the term rapid...

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.

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.

Let's hope they aren't 100% compatible!

Heh, true. I almost wrote "bug-for-bug compatible", but realized how foolish that would be.

Resist complaining about being downmodded. It never does any good, and it makes boring reading. From http://news.ycombinator.com/newsguidelines.html

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.

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.

In my experience, the corrective upvotes happen without calling out that the downvotes are happening.

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.

Who says they disagree? Your post was just spam, saying all the obvious things everybody already knew.

I would love to see a statistical analysis of this. :)

If Debian/Ubuntu replaced Bash for Dash as standard shell I don't know any reason why MacOsX can't do the same.

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.

> How long ago did that happen?

Debian shipped dash as default shell in Squeeze, which was in testing from 2010-08-06 and stable from 2011-02-06.

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

> and only customers that had enabled the apache2 instance and configured it with non-default mods were possibly affected.

Oh, you mean host any website that isn't a single static html page .... :/

This isn't the 1990's anymore. There are plenty of ways to host non-static sites without CGI.

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.

a few questions for you:

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.

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"

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

> But this doesn't fix all the issues known to exist currently.

Apple's certainly gotten a late start, but the "1.0" part of the update's name speaks to an expectation that this isn't the end of the line here.

Probably everything that is new gets a "1.0" designation, just in case.

Just a heads up this page and the url download are over http, the https pages are totally broken. https://support.apple.com/kb/HT1222

The .pkg is signed, otherwise it won't run (unless you have disabled that feature, in which case you are driving around without seatbelts anyway)

For anyone curious, the package installer will refuse to run on Yosemite, declaring it requires OS X 10.9.

(Of peripheral interest, whilst checking in the iOS Dev Center, I noticed there's a beta of iOS 8.1)

yeah, despite the statement: "OS X Mavericks v10.9.5 or later"

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.

Highly likely. I don't see why Apple would "patch" something that's not out yet.

Since we didn't see another DP this week, I'm assuming the Bash update will appear in the RC... hopefully that's out soon.

Yep, and if you're really hard up to get it into 10.10. Just extract the relevant binaries from the 10.9 version.

Though a better question would be what the hell are you doing with 10.10 that you need to. OS X betas are very much beta.

https://gist.github.com/mitchty/6e835bb51735099b6eba

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

Game Over

[1] http://alblue.bandlem.com/2014/09/bash-remote-vulnerability....

[2] http://apple.stackexchange.com/questions/146849/

Unless you're talking about 10.6 or older :

Quoted from 0x0

Also for 10.8: http://support.apple.com/kb/DL1768 And for 10.7: http://support.apple.com/kb/DL1767 Edit: Further information from the announcement is available here: http://lists.apple.com/archives/security-announce/2014/Sep/m....

Just posting it here incase someone reads your comment and misses 0x0's

Any reason this is not showing up in the App Store Updates page? (sorry, I'm still getting my head around OS X...)

It'll take some time before it shows up, but it should eventually (hopefully by tonight or tomorrow morning).

There appear to be updates for 10.9, 10.8, and 10.7, but I can't seem to find one for 10.10 (and yes, 10.10 beta 3 is vulnerable).

I guess us Yosemite users will have to wait for the next beta...

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.

https://github.com/tjluoma/bash-fix

This is the easiest way I've found to patch the system-level /bin/bash AND /bin/sh binaries.

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.

10.10 isn't out yet. It's BETA. So that is a reasonable expectation.

Word of warning, if you have chmod 0000 /bin/bash put it back to how you found it before running the update.

If you didn't do this: cmd + s to boot in safe mode. /sbin/mount -wu / and chmod bash back to a useable state, if you get stuck at log in.

  (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?

Wait, so can anyone tell me what the risk is if you don't apply this update?

Unauthorized remote code execution. ... so pretty much worst case scenario

Its the Shellshock security vulnerability.

http://www.pcworld.com/article/2688672/two-scenarios-that-wo...

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.

This is a really good point. This could easily turn from something that is a remote exploit to some sort of OS independent malware/worm.

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.

It's not a complete fix. This still returns 'not patched':

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

Isn't it supposed to? Forbidding child bashes from inheriting exported functions would surely break quite a bit of code.

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.

[0] http://www.openwall.com/lists/oss-security/2014/09/25/13

The namespace change is an official patch now:

https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027

Ah, that seems a good way of going about it.

You are the only person who basically answered my question in a reply. Thanks!

It's my understanding that the vector for end users would be DHCP in a coffee shop, but I could be wrong.

I'm 99% sure that does not apply to OS X.

As I read it before DHCP is implemented in the kernel in OS X and not glued together with bash scripts like in some cases in Linux.

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.

Yes OSX is not vulnerable to the DHCP exploit.

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.

Ahh, yep. The POC was definitely from server to client, not the other way around. A huge concern for Linux laptops then.

at least until the `apt-get upgrade` or similar :)

> I may be wrong here, but I'm pretty sure as long as you aren't running any network services, you are probably ok.

Would you say the same about Linux desktop users? Or do we tend to run Bash for more things? I'm unfamiliar with bash's role in OSX.

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.

And what if my bash has been moved?

Why on earth would you do such a thing?

Avoid bash vulnerabilities?

Following instructions on Hacker News about immediately avoiding the issue while a patch was unavailable...

Apple's patch won't work for Yosemite, so I'm stuck there too.

If your bash has been moved, then scripts which explicitly reference /bin/bash are going to have a bad time.

I see no downside to this.

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.

[1] "man 3 system"

    System Requirements
    OS X Mavericks v10.9.5 or later

so, they're not updating older machines? My partner still runs Snow Leopard 10.6.8!

Links for: Mountain Lion http://support.apple.com/kb/DL1768 Lion http://support.apple.com/kb/DL1767

Source: http://www.512pixels.net/blog/2014/9/apple-posts-bash-update...

Thanks for the clarification. Still a shame I'll have to install XCode on her machine to get a newer version of bash compiled and installed...

Looks like 10.6 isn't supported, but there are older versions supported: 10.7: http://support.apple.com/kb/DL1767 10.8: http://support.apple.com/kb/DL1768

Looks like 10.6 hasn't been updated in a while.

http://arstechnica.com/apple/2014/03/snow-leopard-updates-ar...

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

Check out witch? It helps with alt-tab

Can't teach her Alt+Tilde? (er, Alt-Backtick really)

Multitouch guestures aren't mandatory, good old mouse and click will work just as they always have.

CMD-~ cycles through windows. hold-click or right-click on a Dock icon displays a list of Windows associated with the application

Alternatvely, perhaps she might like Exposé (try F3)

>> .. taskbar-style way to switch windows http://brawersoftware.com/products/ubar

Apart from that, even on 10.6, you can do the update of Bash yourself, you're not required to use the Apple patch: https://github.com/ido/macosx-bash-92-shellshock-patched

This has been compiled on Mavericks, it may run on 10.6. If not, you may need to install Xcode

> [..] 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.

You can reduce the above 5 steps to just one if you want to do it for the currently open application by pressing CTRL and DOWN :)

Or you could just cmd-TAB to the right application then cmd-` to the right window.

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

...downvote a bit unfair, surely, the patch is trivial to release for all versions (since Bash hasn't been updated across them, IIRC).

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.

  > something that's still perfectly functional

More functional, sometimes; I have 10.6.8 on my home Mac Pro because 10.7 removed a vital feature.

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.

http://arstechnica.com/apple/2014/03/snow-leopard-updates-ar...

http://hacksagogo.wordpress.com/2014/10/02/shell-shock-os-x-...

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.

Worked on my Lion MacBook Pro. Went to the terminal which previously said "vulnerable", redid the command, now ok.

Anybody know what took them so long?

Because they just upgraded to xcode 6.

No surprise it doesn't work on 10.10.

no https? no checksums?

All of Apple's OS updaters are signed by Apple's internal CA and verified at install time -- that's why there's no checksum: http://idzr.org/ba4o

What about the handful of 10.5 machines still running?

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.

Mavericks is apple's Windows Vista

"OS X Mavericks v10.9.5 or later" doesn't include Yosemite.

Yosemite isn't out yet except in Beta. So that is understandable really.

That doesn't make any sense. Yosemite is on DP and Public beta, yet still vulnerable. One thing has nothing to do with the other.

We will probably get another DP tomorrow as it has been two weeks now since the previous DP

They updated Xcode and iOS today, no DP. Makes me think we'll see the RC, maybe, hopefully.

Website says `OS X Mavericks v10.9.5 or later` but fails to run in Yosemite with the error alert:

> This update requires OS X version 10.9.

Before:

   $ bash --version
   GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)

After:

   $ bash --version
   GNU bash, version 4.3.26(1)-release (x86_64-apple-darwin13.4.0)

Huh?

I didn't get that at all. Are you running ports maybe??

There's no way they're pushing out a GPLv3 version of bash, you sure you didn't confuse it with a brew/macports installed version?

From Apple's email announcement http://lists.apple.com/archives/security-announce/2014/Sep/m...

* The version after applying this update will be:

    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)

Indeed,

   port install bash
   cat /opt/local/bin/bash >> /etc/shells
   chsh -s /opt/local/bin/bash
   mv /bin/bash /bin/bash-apple
   ln /opt/local/bin/bash /bin/bash

solves the problem.

Reply on news.ycombinator.com