“A new vulnerability has been discovered in the bash shell which is affectionately being called ‘shellshock.’ It’s worth pointing out that this is quite serious and should be addressed,” David Acland reports for Amsys. “The bash shell is built into almost every Mac OS X system (I say almost, as some clever person may have decided to remove it from their Mac).”
“The shell has a small bit of code that it runs without question on certain older versions of bash. This code can be modified very easily so the attacker can add their own ‘bits’ into it to give them access to your Mac and do as they wish,” Acland reports. “From what I can gather it seems like this is only really a problem for computers that have some kind of external access enabled such as SSH or a web service. Some people have said “well that’s ok, I’m not running a web server”. The problem is, you probably are. A lot of applications start up a small web service to perform their functions, not to mention the cups service running on port 631 that is accessible through a web browser by going to http://localhost:631.”
Acland reports, “After a bit of digging, I decided that upgrading my bash shell was the simplest course of action so here are some instructions.”
How to upgrade in the full article here.
Related article:
U.S. government warns of Bash flaw affecting Apple’s OS X, other Unix-based systems – September 25, 2014
oh bashit
Be careful what you inject into your system,
today’s high could be tomorrow’s addiction!
Fear as in FUD
How so? I checked 10.6.8, 10.9.5 and 10.10 — they all have the vulnerability.
At this point, you really don’t want to run installer packages from sources you can’t verify!
no shit Sherman. You’ve single handidly saved the f*cking world.
So your one of those, ya know, deluded Apple fanboys who thinks Mac’s are secure and can’t be hacked. Wakey wakey!
Chuck you farley
This time it most definitely is not FUD. This affects virtually every UNIX and Linux out there, and it’s a serious threat. OSX is vulnerable. Follow the howto and patch your bash.
Now, probably more importantly given that they’re used on public networks more often, does anyone know whether iOS and Android devices are vulnerable to this too?
Time for another headline roundup:
“Report: Apple bent on Bashing OS Update problems.”
The CUPS web interface is disabled by default on recent versions of OS X — it has to be specifically enabled.
Just checked my Macs, which are all running 10.9.5. Disabled on all of them. Appears to be a big deal about not much.
I wonder if some printers may enable it?
Mine is disabled, so i’ll just wait for a security update. (Which I assume will be shortly)
For those that say this is FUD..
“A lot of applications start up a small web service to perform their functions”
So while it technically affects all Macs.. few may actually be vulnerable cause it is disabled by default, but some apps may turn it on.. and as we all know.. not everyone runs the same apps.
Wonder if some of the apps only turn it on when the app is running? and turn it back off when they close..
This is a huge problem for anyone running a web server – these people should patch their servers immediately.
For a typical Mac, however, this isn’t much of a concern. OS X is technically vulnerable, but it is unlikely you have enabled the type of network access that would make your computer an easy target for outsiders to use this. Apple will release a patch for this in a few days, long before anyone develops a clever way to use this exploit on regular Macs.
Here is a procedure for patching the problem, from StackExchange:
http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7
Ars Technica has a script that demonstrates the problem, and can be used to confirm the fix:
http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/
(I’ve verified the procedure; it works.)
I’ve tried the method provided at Apple.StackExchange.com several times. It consistently runs into this problem:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
This was after making certain Xcode 6.0.1 was installed, booted and activated. I haven’t dug any further into the problem. I’ve tried a couple other methods as well. NONE of them work adequately. But note that I loathe CLIs. I only use them when forced to specifically because of annoying stuff like this. I find it to be RARE that a tech geek is capable of actually explaining how to do something correctly or adequately. 😛
As for the test method: It’s very simple and points out that 10.9.5 has NOT been patched. The Xcode command tools updated did NOT patch the problem.
These work arounds don’t work. The instructions are missing steps. You can download the latest one but they don’t tell you how to remove 3.5.2 and replace it with version 4. Apple will run a software update that will do all of this for you and you won’t have to pull your hair out to do it this way.
I expect that we will see a software update by Tuesday, September 30.
You are quite CORRECT b9bot. As I ranted above: I find it to be RARE that a tech geek is capable of actually explaining how to do something correctly or adequately.
Stop voting b9bot down folks unless YOU can provide an update method that actually WORKS. Then you have my permission. 😉
… got this:
-e:1: syntax error, unexpected tLABEL, expecting keyword_do or ‘{‘ or ‘(‘
-faSL https://raw.githubusercontent.com/H…
^
-e:1: unknown regexp options – raw
-e:1: syntax error, unexpected ‘)’, expecting end-of-input
Is it missing a “(“? That would seem likely, as another error sees the “)” at the end.
That “raw” is a regexp??? Perhaps another error led to this “error”?
I followed the instructions, bash 4.3.25 compiled without problems (which by the way does not replace /bin/bash but is written to /usr/local/Cellar/bash/4.3.25/bin/bash) but when I run the vulnerability test I still get the “vulnerable” message.
Right, because your PATH is not pointing first to the Homebrew version.
Type:
which bash
and you should see that it’s still looking at /bin/bash
You really want the entire system seeing the Homebrew version because unless you’re the one writing the exploit, the hackers out there will not be using your profile and therefore your PATH… you could (I haven’t tested this and am typing in an uneditible blog post feedback field) move the vulnerable executable aside using the mv command, then either copy into /bin/ the Homebrew one or create a link to it. There may be real security implications in that which I haven’t considered. Personally, I’m waiting for the inevitable Apple patch.
Thanks for pointing this out.
If a modify the test to read
env x='() { :;}; echo vulnerable’ /usr/local/Cellar/bash/4.3.25/bin/bash -c ‘echo hello’
it prints
warning: x: ignoring function definition attempt
which means the new bash is immune to the shellshock bug
Now I will move /usr/local/Cellar/bash/4.3.25/bin/bash to /bin/bash
Just in case it doesn’t go without saying, confirm permissions and ownership on the executable after having moved it.
thanks again
http://localhost:631
Just click on that in the MDN article and it will open a tab that will show cups either disabled or in use.
Yet another overblown security issue that there is no exploit for and chances are >98% of Mac users don’t have anything enabled that would cause it to be an issue. Is it a problem, course it is, should be fixed, of course, but trying all those home brew fixes will probably screw up more things than they’ll fix and Apple will more than likely patch it soon, and in the mean time, nothing will happen..
We’ll let you know when you can extract your head from the sand by sounding the ‘All Clear’. You need not know what the rest of use, who comprehend computer security, are doing in the meantime.
But Mac’s are safe and secure…..oh wait a minute!
NO ONE with any comprehension of computing EVER said ‘Mac’s are safe and secure’, ‘have not malware’, ‘can never be hacked’, vomit puke barf. That’s ENTIRELY mythology from newbies and the ignorami.
There is no such thing as “perfect”, secure computer code unless it’s something dead simple. The single biggest problem is the inherent bad memory management of all C-derived programming languages. The vast majority of security flaws are due to memory overruns and their consequences. We’re still waiting to see if Apple’s Swift coding language has overcome the problem.
Chuck the troll.
Dash Riprock