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