Apple is not addressing the Bash bug | Hacker News Reader

Apple is not addressing the Bash bug

plus.google.com

49 pointsesolyt45 comments

Apple has explicitly said that they are addressing the bash bug, and that they will issue a patch for it as soon as it is ready.

> "we are working to quickly provide a software update."

http://www.huffingtonpost.com/2014/09/26/shellshock-bug_n_58...

Want to get mad at a company? How about Netgear, which as far as I can tell has provided no official statement, warning, or patch for their consumer routers and APs.

Or how about LG? I have an LG Linux-based smart TV and I can't find one thing they've said about Shellshock. (In fact, I have not received a software or firmware update to that TV for well over a year at all.)

Or how about Synology, who said almost the exact same thing Apple did. Where are the posts suggesting we all stop putting our data into Synology NAS?

> A thorough investigation by Synology shows the majority of Synology NAS servers are not concerned. The design of Synology NAS operating system, DiskStation Manager (DSM), is safe by default. The bash command shell built-in in DSM is reserved for system service use (HA Manager) only and not available to public users. For preventive purpose, Synology is working on the patches addressing this bash vulnerability and to provide them as soon as possible.

Synology is based on BusyBox, so their shell is ash, not bash. So in their case, it's true, they're not vulnerable. Apple has no such excuse.

Many routers will similarly be using ash/BusyBox, though I agree they should issue a statement.

“The vast majority of OS X users are not at risk to recently reported bash vulnerabilities… With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.” -Apple

Apple says they are working on a fix. Given that other vendors like RedHat had to issue multiple patches before they finally squashed the bug, I think it is far too early to claim that Apple isn't fixing this in a timely manner.

Sorry, but you have no idea what you're talking about.

The first patch released took the exploit from "Know way to easily remote execute code" to "Parser error that might be exploitable but we're not sure how to actually use it". If the Linux/BSD world had stopped there, they still would have done a far better job than Apple has. But they didn't stop there. They released a second patch. And now everyone is secure.

Meanwhile, the rest of the world and I are watching through our Apache logs as attackers are knocking at our front door with this exploit. If you have a OS X server and you didn't patch it already, you may already be exploited.

Apple really got off super easy on the iCloud thing. As the article alludes to, they knew for months before the break-in, heck a lot of people on HK knew for months before the break-in (there was an article about it months ago) and yet they did nothing. Then when someone utilised that well publicized issue to break into accounts they pretended like they couldn't have seen this coming and it was a "targeted break-in" whatever the heck that means.

If it was any other company they would have got shit all over. Apple just has a very poor security culture internally, they're like Microsoft pre-Windows XP SP2. Microsoft made a huge cultural shift, it is about time Apple do the same.

>> "Apple really got off super easy on the iCloud thing"

I think you're confusing two separate issues here. There was a flaw in iCloud but the photo hacking incident which some seem to be alluding to ("break-in") was, from what I've read, done through phasing attacks, password/secret question guessing, and general social engineering rather than through a hole in iCloud. The two things were unrelated.

You realise the flaw in iCloud was that it allowed unlimited password guesses[0], right? So in effect what you just claimed is that the attackers used the known flaw in iCloud but that the two incidents are "unrelated."

If attackers used dictionary attacks or brute forcing against iCloud's APIs then that is the very flaw of which we speak. Everything I've read is that they did do exactly that, therefore it is easy to claim that the flaw and the theft are related.

[0]http://www.macrumors.com/2014/09/25/apple-icloud-flaw-six-mo...

> While it should actually be a reasonable assumption, this is likely inaccurate both concerning public servers

Funny, I have personally worked at a company which ran their frontend on Mac Mini's. They weren't using CGI, but at least part of the assumption that people don't run Apple web servers is false.

Also, Mac supports running an Apache instance configured to run CGI scripts out of the box, correct? I haven't personally used it.

> Also, Mac supports running an Apache instance configured to run CGI scripts out of the box, correct? I haven't personally used it.

OSX does have Apache configured by default to run CGIs out of /Library/WebServer/CGI-Executables, but there is nothing in that folder by default, and you have to manually start Apache yourself, either with apachectl or via the System Preferences GUI.

    /etc/apache2/httpd.conf
    96:LoadModule proxy_scgi_module libexec/apache2/mod_proxy_scgi.so
    106:LoadModule cgi_module libexec/apache2/mod_cgi.so
    331:    ScriptAliasMatch ^/cgi-bin/((?!(?i:webobjects)).*$) "/Library/WebServer/CGI-Executables/$1"

That's what I thought. And regardless of the manual steps required, it makes the stance of "nobody uses macs as web servers" completely untenable.

There is a handy script 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 required.

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

(yes, you have zsh on OSX by default)

Worked for me, thanks!

For anyone wanting to patch their Mac (especially any older Macs, right back to 10.4 PPC) to the latest 4.3.27 bash without compiling themselves, TenFourFox posted a binary a few hours ago & some simple Terminal instructions:

http://tenfourfox.blogspot.com/2014/09/bashing-bash-one-more...

TenFourFox are the people behind Firefox for old PPC Macs. The binary they posted today includes a patch for CVE-2014-6277, which bash 4.3.26 didn't have.

Is it worth filing radars with CVE references to put some pressure on this?

Fix has been released: http://support.apple.com/kb/DL1769

Maybe I'm not doing things right, however, when I run the test code for shellshock my 10.9.4 box seems immune.

Maybe it's homebrew patching it...

It's definitely homebrew, Apple hasn't patched their binaries. Don't let this give you to a false sense of security. Many scripts could still be hardcoded to use your vulnerable /bin/bash binary, and many more won't load the PATH variable from your ~/.bash_profile. The only way to fix the problem is to patch /bin/bash and /bin/sh, updating homebrew is not nearly enough.

Homebrew has patched Bash for all 3 recently announced vulnerabilities, yes. The vulnerable bash will still be lurking on your system though, in /bin/bash and /bin/sh.

My 10.9.5 box fails the tests.

What does

  /bin/sh --version

give you?

try this then:

$ env X="() { :;} ; echo busted" /bin/bash -c "echo wow"

that'll pop out of usr, so you'll fail.

Yup, definitely busted.

Isn't Apple stuck to an old version of Bash due to the GPL, just like they were with GCC?

That’s completely irrelevant, since there are patches for all old versions of Bash.

Yes, but there's another issue.

Apple hard links /bin/sh to bash.

They could switch /bin/sh to an Almquist shell like dash to mitigate Shellshock.

I believe that they can provide a patch for the old version if they release the source to said patch.

Isn't this irrelevant since no one is 1) using CGI on Macs and 2) no one is using a Mac as a server?

1) CGI is only one known way to exploit shellshock. There are probably many others.

2) People do use Macs as servers. It's unwise, clearly, but it is done. https://www.apple.com/osx/server/

3) OSX server is setup for CGI by default, all you have to do is throw some scripts in the right directory.

i belive the bug can be used to execute code on your mac with a dhcp server

https://www.trustedsec.com/september-2014/shellshock-dhcp-rc...

The attack surface for shellshock is insanely large, and it's crazy to leave bash unpatched even if one or two currently-known vectors happen to not currently be known to be exploitable. People will be finding ways to tickle it for years to come.

Incorrect. OS X does not use bash scripts for DHCP client tasks and was demonstrated to NOT be affected.

The DHCP vector was demonstrated to be an issue with various Linux distributions.

That's not applicable here. Even NetworkManager on Linux isn't susceptible to this hack. dhclient and dnsmasq can apparently be shocked on unpatched Linux, though.

The fact the post was shared on Google Plus speaks volumes.

Would you like to expand on that comment? What does it mean when a post is shared on Google plus?

I think he means it contains a pro-google / anti-apple sentiment.

So getting back to shellshock on OSX...

Is there a patch available?

yes.

Does it download via a GUI?

no.

Is it about the same level of effort to patch a OSX box as a GNU/Linux box?

yes.

Does the post go wildly offtopic to address issues (iCloud) that are likely wetware hacks? yes.

Does it recommend carte blanche to not use apple products because their OS is fully patched? yes.

Um... the effort I had to take to patch my linux boxes was: Do nothing. (security fixes had been released and installed before I learned of the bug).

The effort I'll have to take to patch my Mac is:

* Download a new bash.

* recompile it

* install it by hand.

(and this is assuming I already have xcode/developer tools installed).

Not quite the same level of effort.

Is the article wildy off topic? Not really - its an article about yet another instance of Apple ignoring security issues, why wouldn't a previous example be relevant?

What is the software vulnerability used for the iCloud hack?

Is your position that a software vulnerability the only type of security issue? Is your position that ignoring software vulnerabilities is fundamentally a different thing than ignoring other types of security issue? I'm confused by why you are asking.

About the same level of effort?

Linux: apt-get install bash

OS X: Install xcode, install xcodetools (CLI), download bash source code from a mostly-undocumented URL (need to search through apple support forums), download and manually apply patch from GNU. Build bash, manually copy build output into /bin.

Yeah, totally the same level of effort.

You can install the Xcode CL tools without installing Xcode. The two were separated a couple years ago.

Did you mean to say 'brew upgrade bash'?

That doesn't change the version of bash pointed at by /bin/sh which is a hardlink to the OSX supplied bash. Even if you previously relinked /bin/sh to a homebrew bash, it won't change versions by upgrading the installed bash.

I suppose if you're being brave, you can nuke the built-in bash and symlink it back to brew's copy.

Which volumes are those?

Wiesmann's "Treatise on Tinfoil hats", volume one through three.

Reply on news.ycombinator.com