[pudquick]

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.

[0x0]

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.

[pwg]

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

[yaeger]

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"

[milkshakes]

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)

[alayne]

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.

[eridius]

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.

[dangerlibrary]

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

[eridius]

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

[pmarin]

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

[eridius]

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.

[jdub]

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

[masklinn]

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

[dfc]

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

[eridius]

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.

[scott_s]

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

[eridius]

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.

[SamReidHughes]

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

[scott_karana]

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

[dfc]

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.

[eridius]

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.

[tenken]

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

[emgee3]

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

[Thesaurus]

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