
Apple is not addressing the Bash bug - esolyt
https://plus.google.com/+supercurioFran%C3%A7oisSimond/posts/BpesETubZzP
======
snowwrestler
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...](http://www.huffingtonpost.com/2014/09/26/shellshock-
bug_n_5888204.html)

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.

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

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

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

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

~~~
k-mcgrady
>> "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.

~~~
Someone1234
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...](http://www.macrumors.com/2014/09/25/apple-icloud-flaw-six-months-
before-hacking/)

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

~~~
unspecified
> 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"

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

------
unspecified
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](https://github.com/tjluoma/bash-fix)

(yes, you have zsh on OSX by default)

~~~
cheshire137
Worked for me, thanks!

------
SyneRyder
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...](http://tenfourfox.blogspot.com/2014/09/bashing-bash-one-more-time-
updated.html)

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.

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

------
0x0
Fix has been released:
[http://support.apple.com/kb/DL1769](http://support.apple.com/kb/DL1769)

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

~~~
wmil
My 10.9.5 box fails the tests.

What does

    
    
      /bin/sh --version
    

give you?

~~~
fleitz
$ /bin/bash --version GNU bash, version 3.2.51(1)-release (x86_64-apple-
darwin13) Copyright (C) 2007 Free Software Foundation, Inc.

~~~
m3mnoch
try this then:

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

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

~~~
fleitz
Yup, definitely busted.

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

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

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

~~~
y0ghur7_xxx
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...](https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-
concept/)

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

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

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

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

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

~~~
fleitz
Did you mean to say 'brew upgrade bash'?

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

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

