Apple Yet To Push Patch For "Shellshock" Bug

An anonymous reader writes "Open source operating systems vulnerable to the Shellshock bug have already pushed two patches to fix the vulnerability, but Apple has yet to issue one for Mac OS X. Ars Technica speculates that licensing issues may be giving Apple pause: "[T]he current [bash] version is released under the GNU Public License version 3 (GPLv3). Apple has avoided bundling GPLv3-licensed software because of its stricter license terms....Apple executives may feel they have to have their own developers make modifications to the bash code."" It's also worth noting that there are still flaws with the patches issued so far. Meanwhile, Fedora Magazine has published an easy-to-follow description of how Shellshock actually works. The Free Software Foundation has also issued a statement about Shellshock.

Comments

Re:~/.cshrc

[oneiros27]

Oh, you think you're kidding ... but the problem isn't just bash ... it's that Apple uses bash in place of sh.

So most programs that shell out (php, perl, etc) are potentially vulnerable no matter what initial shell they were called from:

csh< env x='() { :;}; echo vulnerable' perl -e 'system "echo test;"'
vulnerable
test
csh>

Re:~/.cshrc

[fnj]

Rename /bin/bash to /bin/bash.bak then create a link [cyberciti.biz] from /bin/dash to /bin/bash ..

And get ready for a whole lot of scripts failing. Scripts that start with #!/bin/sh but are written dependant on bash features will fail. Scripts that start with #!/bin/bash on the other hand will just fail to start. You'll have a busted-ass system, but at least it won't be attacked.

Now if you were running debian or ubuntu /bin/sh would already be a link to /bin/dash, and there wouldn't be any screwed up scripts because the design of the file layout was made by people who weren't brain dead.

Re: Issue with FSF statement...

[Anonymous Coward]

An hour? Well, you probably learnt some things during that hour.

Now, I told a Mac-using colleague about shellshock on Thursday morning, told him what to type at the terminal to verify that his shell had the bug, went to get a cup of coffee, came back to my desk, and there he was already waiting to say, "There, I've patched it". And he had, too.

Re:~/.cshrc

[Concerned Onlooker]

"Unfortunately, based on my extensive experience with OS X, I have to say that it is a big pile of shit. "

Don't stop there. Give us some real examples of why you think this. Because otherwise it kind of sounds like you're just making something up that sounds authoritative but really isn't.

Re:~/.cshrc

[Kiwikwi]

It really has nothing to do with the default shell. It won't matter what shell is the default when your CGI script starts with #!/bin/bash.

No, no, no, no... People really don't get the scope of this.

It doesn't matter what the default user shell is, or what language a CGI script is written in. Bash is the most common system shell, which means it's invoked all the time when other programs run commands.

Obviously, I can't know this, but OP is probably not using csh as his system shell, because that's not POSIX compliant and would cause major breakage.

If /bin/sh is Bash, you're vulnerable, no matter what shell you're using yourself, or what language your CGI script is written in.

Also, CGI scripts is only the most obvious attack vector; others that have been identified so far are the CUPS printing daemon, the ISC DHCP client and locked down SSH shells like those commonly used to host Git repositories. But there are without doubt many more. The only safe thing to do is to upgrade or remove Bash from your system immediately.