Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple: Most OS X Users Safe from 'Bash' Security Flaw, Software Update Coming Soon
- Thread starter MacRumors
- Start date
- Sort by reaction score
You can't. The person doesn't know what they're talking about. Please see my other posts for accurate info.
Last edited:
A lot of the stuff you heard people panicking about was never going to happen.
But the reason almost nothing happened at all was because people put a lot of work into making sure nothing would happen.
thanks. that's what I thought and I was wondering if I am missing something.
yes, if you start modifying your standard ssh settings by monkeying with /etc/sshd_config or something then I can see this possibly becoming an issue but no regular user would ever get there.
VNC? possibly not, unless it has a way of configuring environment variables when opening the session.
Apache? Yes, if you have mod_cgi enabled. and possibly mod_php5. You'll want to keep a tight lid on those, and made sure that system() is disabled in PHP (I believe it's a configurable option in php.ini, but definitely is an argument to ./configure).
This issue isn't just Apple's. As I mentioned before, every version of Unix or any Unix-like OS that has bash as part of its software distribution is vulnerable to this. Bendghazi and iOS 8.0.1 are Apple's bad week; Shellshock is Unix's bad day.
BL.
Y2K was a self-fulfilling non-prophecy. In most cases, simple to fix or work around. But, necessary. Because "management" and the general public don't take software safety, reliability, and security seriously, it is necessary (apparently) to over-hype these issues in order to get some kind of response. Perhaps if they start teaching kids in Middle School about these issues, the problem will go away in 30 years ...
Last edited:
This is not an apple bug!
bash is a program developed by the GNU foundation and relied upon by most of the *nix community. It is distributed with almost every variant of *nix and as a result, all of these distributions are vulnerable at the moment. Attacks can be made by injecting code by means such as cgi-bin, dhcp, etc and gaining access to bash remotely.
http://www.gnu.org/software/bash/
Until GNU fully patches the exploit and that patch is deployed by the various distributions, the vulnerability exists.
There is a "first stage" patch out there and as has been linked already, it can be deployed on your mac. There will be a full patch released (I'm guessing very soon) and I'm pretty confident it will be delivered as a patch to any currently supported version of OSX by Apple. If you are running an older version of OSX, someone will deploy a patch for that as well, the open source internet is good that way.
But the bottom line is, if you are not directly internet connected (i.e. if your IP address starts with 10., 172.16(to 31), or 192.168.) then you are very likely protected by your network's firewall and have nothing to worry about.
And honestly, who wants to hack your Mac anyway? Hack 1 Mac, get 1 person of data... Hack Home Depot, get 6 million persons of data.
bash is a program developed by the GNU foundation and relied upon by most of the *nix community. It is distributed with almost every variant of *nix and as a result, all of these distributions are vulnerable at the moment. Attacks can be made by injecting code by means such as cgi-bin, dhcp, etc and gaining access to bash remotely.
http://www.gnu.org/software/bash/
Until GNU fully patches the exploit and that patch is deployed by the various distributions, the vulnerability exists.
There is a "first stage" patch out there and as has been linked already, it can be deployed on your mac. There will be a full patch released (I'm guessing very soon) and I'm pretty confident it will be delivered as a patch to any currently supported version of OSX by Apple. If you are running an older version of OSX, someone will deploy a patch for that as well, the open source internet is good that way.
But the bottom line is, if you are not directly internet connected (i.e. if your IP address starts with 10., 172.16(to 31), or 192.168.) then you are very likely protected by your network's firewall and have nothing to worry about.
And honestly, who wants to hack your Mac anyway? Hack 1 Mac, get 1 person of data... Hack Home Depot, get 6 million persons of data.
Shellshock via DHCP. Ugh.
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
I don't necessarily subscribe to the "blown out of proportions" side but on the other hand, I don't care for the way the news media is reporting this. It is not a concern for most Mac users as far as their computer being compromised--so why even mention Apple in their story. This is a UNIX/Linux issue and because Bash is part of the Linux bundle, Apple is part of the affected crowd. But the majority of any problems will be on web servers--most running apache over some distribution of Linux--so it is certainly in their best interest to patch this immediately--but most of us just don't use those buried Linux commands so all it does is confuse most Mac users.
"That person" actually has been running Linux, Windows and Mac servers for close to 20 years. #
And yes, ssh is exploitable with this, however, as I said, it's very, very hard.
Anyway attack vectors that are likely are 3rd-party apps and DHCP.
What does SSH login have to do with it? Does the authentication process set user-defined env variables? I've read about 4 explanations of this bug already, and they haven't explained it well, so I don't know if I'm right: From what I understand, the flaw is that someone can run a command by making your computer/server set an environmental variable to "() { :;}; insert_command_here". So if you have something taking requests and setting environmental variables based on user input without any checking, you're vulnerable. It's like SQL injection attacks in a way.
Last edited:
Lynx and Pine?
Pine? Ugh.. Couldn't stomach that back in 1993, can't stomach it now.
Besides..
Michael R. Elkins said:
BL.
Snow Leopard was my favorite. Probably the most serious OS Apple has made. A thought has been spared for you.
Last edited:
Many services and apps "shell out" to run commands, setting env vars based on user input. Among them web servers, SSH, DHCP, and others.
Imagine someone managing to exploit DHCP to manipulate your local system and then use it to manipulate things you connect to. Plus there are likely undiscovered variations of this yet.
This is why all systems should always be patched as quickly as possible. Apple waiting to release a patch and saying that normal users won't be affected is dangerous and a sign that they don't have their **** together when it comes to security.
If your CGI script is a bash script, it is probably vulnerable, yes. If your CGI script executes bash directly or indirectly, it might be vulnerable. However, it has been known for 20 years that CGI scripts written in shell script are inherently insecure. This is not news. It is also widely known that shells should not be used to execute anything that is controllable by a user who has lower privileges than the shell.
sorry, I'm not terribly savvy in these matters (just a regular user here) but I still don't understand from your explanation why simply enabling ssh connections on my mac would make things any less secure than they already are while this bash vulnerability is unpatched. you said that ssh sets some env variables based on user input. does any of this really happen before the authentication process is complete? if not why would it be an issue? and if yes why would this be difficult to exploit?
Who makes up these trite "names" for these exploits? "Heardbleed"?? "Shellshock"??
Heartbleed is a SSH exploit and Shellshock a Bash exploit.
Next terrible exploit: Nerveshocker.
Heartbleed is/was an OpenSSL issue, not SSH.
And the /bin/sh point you made is why this is primarily a linux problem. Not to belittle the issue on other platforms.
On most Unix's, "sh" is the borne shell. And bash is bash.
Not on linux though, linux doesn't have a borne shell, its a symlink to bash.
On any Mac OS X system I have administered, I have restored all the shells, to include root's shell to tcsh, and it does just fine.
Maybe (what do I mean, of course you do) you have more linux experience than me, but I have never changed root's shell from bash to something else, without some hickup here and there. I'm not sure if a linux box could successfully run without bash, without some serious digging around to fix stuff.
OS X does it with out a hitch.
Even on old, unsupported versions of OS X, the answer will involve one of (at least) two possible solutions, delete the buggy bash shell and work with one of the other common shells, or, pull down the fixed bash source code and compile your own fix.
----------
Lynx and Pine?
Newbies. What's wrong with Elm?
or just telnet'ing to port 110 and reading your mail straight from the popper daemon?
</humor>
I found a cool article here about this: http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html
Vulnerable HTTP servers will set env variables based on the user agent, cookie, or referer HTTP GET request headers. I don't know which servers these are; my servers and my friends' were all safe. But this guy found vulnerable ones using this method.
I tried it myself on my own server and failed because the option in masscan to send HTTP headers isn't working for some reason. Probably due to the highly managed network I'm on.
----------
This is supposedly fixable on OS X if you've got MacPorts or Homebrew (which you should have). The instructions on this site tell you how to do it. Aaand my FreeBSD server has no Bash installed, so I guess I'm fine.
Vulnerable HTTP servers will set env variables based on the user agent, cookie, or referer HTTP GET request headers. I don't know which servers these are; my servers and my friends' were all safe. But this guy found vulnerable ones using this method.
I tried it myself on my own server and failed because the option in masscan to send HTTP headers isn't working for some reason. Probably due to the highly managed network I'm on.
----------
This is supposedly fixable on OS X if you've got MacPorts or Homebrew (which you should have). The instructions on this site tell you how to do it. Aaand my FreeBSD server has no Bash installed, so I guess I'm fine.
Last edited: