> I'm glad to see Apple rapidly responding
It seems we have different expectations concerning the term rapid... > I'm glad to see Apple rapidly responding
It seems we have different expectations concerning the term rapid...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.
Edit: If you disagree with me, please reply instead of downvoting.
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.
Debian shipped dash as default shell in Squeeze, which was in testing from 2010-08-06 and stable from 2011-02-06.
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. :-)Oh, you mean host any website that isn't a single static html page .... :/
> 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.
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)
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"
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.