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
I am not sure you understand the nature of the problem. You don't have to allow direct remote access to bash. The shell can be invoked indirectly, say by the web server.
What this means is that virtually ALL unix web servers that rely on CGI scripts (quite a lot of them do) are vulnerable. This is a total disaster.
The bendgate is blowing things out of proportion. The bash vulnerability is probably the most severe threat to security we have had so far in the history of internet.
of course, most wouldn't have the know-how to "tinker with the Terminal"
I only only enough to get by by the commands i use only... Why bother learning something you'll never use ?
May be good knowledge to those who need it,but not me.
Plus, Google is always there... It's not going anywhere.
Its only risky if u use SSH, or Terminal internet-facing commands... If you don't, u have nothing to worry about.
I only only enough to get by by the commands i use only... Why bother learning something you'll never use ?
May be good knowledge to those who need it,but not me.
Plus, Google is always there... It's not going anywhere.
Its only risky if u use SSH, or Terminal internet-facing commands... If you don't, u have nothing to worry about.
Sorry, but this is incorrect.
Ssh is vulnerable, although an attacker would have to have obtained login credentials to the system - so it's not as big a deal as on a system running Apache or another web daemon. Note that this also means other utilities that make use of ssh - like sync - are potentially vulnerable with the same caveat.
Also, scripting languages like PHP, python, perl, etc. are considered potentially vulnerable because they make use of system calls for many functions.
Additionally, the people claiming this vulnerability has been patched are incorrect. A patch was released but quickly proven to be incomplete and ineffective.
These operating systems haven't been current for about 20 years. They're likely vulnerable to 100 other remote exploits found since they were last updated.
I understand, I'm not referring to remote access as in being logged in remotely, but passing user input blindly to a shell. That is not the issue here, it's also not an issue with the shell per se.
Data to the CGI scripts is passed via environment variables. By crafting malicious user agent strings or remote user names, you can exploit the vulnerability. This can be as easy as using wget -U
P.S. I know for sure that parts of our web server are affected, because I use bash scripts behind Apache authentication that rely on REMOTE_USER. But because this is an internal-only server, behind a VPN and with very limited access, I am not really worried for the time being. Still, this should be patched ASAP.
Where can I find updates to SunOS 4.1.4? Are you sure you're not thinking of Solaris (which I removed from the list)?
And 2006 was 8 years ago, which is still an eternity in Internet security terms.
Last edited:
Yes? But that is not "allowing remote access", it's a bug in bash. It's distinct difference which I pointed out in the first post.
Not damage control, but reporting the exact facts. 99.99% of MacOS X users have nothing to fear, because they are not running web servers on their Macs. And if you are running web servers, you don't wait for Apple press releases.
----------
"Vulnerable" if you are running web servers on your computer that allow random people on the internet to access your computer. Are you?
Ah, ok, it seems I was slightly confused by your earlier exchange with bradl. Now I understand what you meant.
Why not get a mac mini and use a monitor of your choice ^_^ - I simply could not function with a 2006 computer today.
This just says whether your version of Bash is vulnerable or not (which, unless you've manually updated Bash within the past two days, it is.) It doesn't actually determine if there's any way a hacker could exploit that on your computer.
IE, I'm running VNC and Apache off of a Mac Mini (with port 80 and whatever port VNC uses being exposed to the open internet). Is there some way those could be exploited by hackers? (And I know the VNC is dumb... At some point I want to move from a password system to a key system for it...)
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.
In case someone is missing the reason for these "names":
Heartbleed is about a bug in the OpenSSL TSL heartbeat extension leaking information. Heartbeat leaking -> Heartbleed.
Sheeshock is about a bug in bash, which is a very common Linux and Unix command line shell. Shell -> Shellshock.
Too early to feel safe
You don't need to have exposed services to the big wide Internet to possibly be vulnerable. Just using your computer in a public network might be a risk.
/bin/sh is used in tons of places on Unix computers: getting an IP address when you use a public wifi, printing documents with CUPS (default on all Macs) and probably tens of other system level services.
I don't know how Apple can be sure that normal users wouldn't be at risk. How many third party applications listens on a port or call out to the shell with user input? No one can be sure today.
Fix it now!
You don't need to have exposed services to the big wide Internet to possibly be vulnerable. Just using your computer in a public network might be a risk.
/bin/sh is used in tons of places on Unix computers: getting an IP address when you use a public wifi, printing documents with CUPS (default on all Macs) and probably tens of other system level services.
I don't know how Apple can be sure that normal users wouldn't be at risk. How many third party applications listens on a port or call out to the shell with user input? No one can be sure today.
Fix it now!
So they're puns. Even worse
Heartbeats don't leak. Shells do not become shocked. I thought this was stupid before. Thanks for the explanation, but made up names would have been slightly better than puns.
You must be fun at parties.So they're puns. Even worse
Heartbeats don't leak. Shells do not become shocked. I thought this was stupid before. Thanks for the explanation, but made up names would have been slightly better than puns.
Btw shell shock is, I quote a reaction to the intensity of the bombardment and fighting that produced a helplessness appearing variously as panic and being scared, or flight, an inability to reason, sleep, walk or talk.
http://en.wikipedia.org/wiki/Shell_shock
I was playing with this "vulnerability" last night on 10.6 and it didn't have root access, only the same permissions as the current user and couldn't access or modify any root files.
Not like the days of gaining root access using Unix mail exit to shell bug.
Not like the days of gaining root access using Unix mail exit to shell bug.
So they're puns. Even worse
Heartbeats don't leak. Shells do not become shocked. I thought this was stupid before. Thanks for the explanation, but made up names would have been slightly better than puns.
Xe89 already explained the term "shell shock".
About heartbeats not leaking, that's exactly the reason the issue was called "Heartbleed": the SSL TSL heartbeat extension is definitely not supposed to leak information either... but it does! Hence the bug and exploit.
What I was thinking...
Even a budget i3 hack would be an improvement!
But, I suppose the white iMac was a very beautiful machine. And I have a black macbook and iBook G4 in daily use.