Apple Fixes Shellshock In OS X 174
jones_supa (887896) writes Apple has released the OS X Bash Update 1.0 for OS X Mavericks, Mountain Lion, and Lion, a patch that fixes the "Shellshock" bug in the Bash shell. Bash, which is the default shell for many Linux-based operating systems, has been updated two times to fix the bug, and many Linux distributions have already issued updates to their users. When installed on an OS X Mavericks system, the patch upgrades the Bash shell from version 3.2.51 to version 3.2.53. The update requires the OS X 10.9.5, 10.8.5, or 10.7.5 updates to be installed on the system first. An Apple representative told Ars Technica that OS X Yosemite, the upcoming version of OS X, will receive the patch later.
Why isn't this auto-update? (Score:5, Informative)
I have 10.9.5 and checked for software updates. None. Why do I have to click the link in the slashdot article and manually download the patch?!?!?
Re:Why isn't this auto-update? (Score:5, Informative)
I downloaded and installed this update. It updates bash to version 3.2.53(1), but a patch to version 3.2.54(1) is available on gnu.org. I'm guessing that there will be more updates since additional issues with the parsing in bash have been (are being) found.
Re: (Score:2)
The knowledge base article [apple.com] on the update only mentions CVE-2014-6271 and CVE-2014-7169.
Re: Why isn't this auto-update? (Score:2, Informative)
Why not?
http://opensource.apple.com
Re: (Score:3)
Re: (Score:3)
Bash 3.2 is still under the GPL v2.
Re: (Score:2)
I think Apple is a little leery about being too quick to release patches these days...
Re: (Score:2)
Re: (Score:2)
Yeah, I guess they're worried it will mess up their cloud or phone calls or something. :-P
Re: (Score:3)
Since macs are rarely used as servers the number out there is probably going to be pretty small, so that has to be factored in as well.
Re: (Score:2, Funny)
Yes, the typical use case for a MacBook is serving bash scripts over HTTP. Patch quickly!
AWWWW SHEET, I think I've been HACK#ED! (Score:5, Funny)
I never asked for this...
Re: (Score:3)
Re: (Score:2)
Dirty little secret: OS X is held together with something that smells disturbingly like systemd...
Re: (Score:2)
That's not a "dirty secret". Having a single component that launches all daemons is a laudable improvement over the adhoc, multiple methods that had grown up in Unix like OSs.
Linux has political problems between Linus and the systemd team, and systemd may be overreaching. None of which is relevant to OSXs entirely different component launchd.
And if anyone thinks there's any copying going on here, take note of the direction - OSX launchd dates back to 2005. Linux systemd to 2010.
Re: (Score:2)
There will be. Unfortunately, those who would take over our computers do not share our lack of imagination.
Re: (Score:2)
Re: (Score:2)
It’s really not a gamble for the majority of their customers. Default install ships with neither SSH, nor Apache, nor anything else that could possibly route network input to a copy of Bash enabled by default (both OpenSSH & Apache are included, just turned off). To be expoitable would require manually enabling Apache, then manually editing httpd.conf to enable some kind of CGI binding (none enabled in default shipped config file).
The number of their customers who were actually vulnerable to thi
Re: (Score:2)
Erm, you talk about Macs? No?
Yes, they are distributed with an Apache web server and SSH.
If you consider "manually enabling" similar to clicking the check box in the "sharing" section of "system preferences" then it is indeed a hard job for the typical Mac user! (* facepalm *)
And you are an admin for macs and don't know they come with Apache httpd and SSH preinstalled?
Re: (Score:2)
Re: (Score:2)
And at 3.3M they may as well just push it out rather than delaying it. A couple of checks will be more costly than just letting everyone download it straight away.
Re:Why isn't this auto-update? (Score:5, Insightful)
Because of many reasons.
First off, the patch isn't complete. Sure there was a patch last week, but did you know it didn't fix the problem? Yes, it fixed the obvious error, but there were still more (and new CVE was opened for Shellshock). Bash devs are still finding more holes related to this issue, and it goes down a deep rabbit hole. This hole may never be full patched for a long time.
Second, there aren't many OS X systems that are exploitable. Remote exploits require a server to take parameters, format them as environment variables and then call the shell (usually through system()). HTTP and CGI scripts are a common vector because that's exactly how they work. Most webservers out there run Linux and there really isn't a special reason to run OS X + httpd + CGI over running it on Linux especially on a public server. So for the scant few servers, those admins can update the shell.
And on OS X, the webserver is disabled by default and most users won't know how to turn it on. I don't think even OS X server has it on by default - given the server is really just a bunch of admin tools nowadays.
Third, well, I don't think many OS X apps actually bother using a call like system() to perform a task - there's probably a native Cocoa API that is supposed to be used instead.
So it's more of a hotpatch for those few machines that are potentially vulnerable. In fact, the patch that was provided last week wasn't fixing the issue, more working around the issue so it's harder to exploit (i.e., instead of an arbitrary variable containing a function, it has to be prefixed with _BASH_FUNC_ in order to be allowed as a definition).
There is currently no root-cause fix for the issue - it's actively being worked on by Bash developers and others. This isn't like heartbleed where the mistake was a little programming oversight - it's a full on design issue that dates back 20+ years. There are probably going to be dozens of patches to fix the issue in the end.
Re: (Score:2)
> it has to be prefixed with _BASH_FUNC_ in order to be allowed as a definition)
What's stopping me passing _BASH_FUNC_ in a HTTP request to a BASH CGI script?
Re: (Score:2)
>that setting a variable whose name starts with _BASH_FUNC_ is going to be nigh impossible through a standard HTTP interface.
But that's exactly what I did by appending ?_BASH_FUNC_thingy=myattack to a url to a CGI script.
Re: (Score:2)
Fortunately for the evil doers, they don't have to be bound by past vulnerabilities.
Just give it a name that the script already uses.
If the script uses functions passed through the environment variables, it is now going to be written such that those variable names are prefixed with _BASH_FUNC_ because the new changes require it. So the attacker follows suit. The point being that the attacker can indeed modify the name and he or she or it can modify it to suit the script being attacked.
The underlying problem
Re: (Score:2)
Re: (Score:2)
I don't understand, can you please express this as a car analogy.
Re: (Score:2)
My question is whether this is a full patch, or just the partial one that they've been talking about for most *nix distros.
I have an idea (Score:2)
How about releasing a version of bash that has function passing disabled. That would be safer and we can find out what breaks.
Re:I have an idea (Score:5, Funny)
How about releasing a version of bash that has function passing disabled. That would be safer and we can find out what breaks.
If only bash were open source, one could do this themselves instead of hoping others might do it for them.
Re: (Score:3, Interesting)
Re: (Score:2)
Hey, the last update is 4 days ago. What have you guys done for me recently?
Ahh yes (Score:2)
Everyone should just go and learn C and how to do POSIX programming, attain enough mastery in it to be able to diagnose code for obscure security issues (that have eluded many programmers for years) and then design a secure fix.
And they should do that in a day.
Ya that sounds reasonable.
FYI not only are most people not programmers, and have no interest in becoming programmers, but most lack the kind of brain it takes to be a good programmer. The whole "Oh it is OSS fix it yourself!" argument is a really stup
Re: (Score:2)
This sounds needlessly complicated. Let's just each do what we can for others in, say, seven hours on four days of every week, and leave the rest to our leisure.
So... you're suggesting that we apply the open source notion of "everyone works on what interests them" to all productive labor? While I'm a big fan of open source, that approach has real and obvious problems. Are you going to volunteer to maintain the sewage treatment plants?
Re: (Score:2)
If I can't otherwise have sewage treatment -- yes, definitely.
Re: (Score:2)
If I can't otherwise have sewage treatment -- yes, definitely.
And the 10,000 other, similar, issues? There are lots of things that need to be done but no one really wants to do. If the solution is that everyone must do those things themselves then we lose much of the advantages of specialization.
Re: (Score:2)
While I'm a big fan of open source, that approach has real and obvious problems.
The problems show themselves just as much in software as anywhere else. e.g. People would much prefer to create new code than do code reviews or write tests, so defects in open source software linger around for a decade or two.
Exactly. The approach does have a lot of benefits, but there are some negatives as well.
Re: (Score:2)
...or you could do it yourself, BASH is open source.
Re: (Score:2)
...or you could do it yourself, BASH is open source.
Maybe the GP is not a programmer and is thus not able to do it himself. Open source is great but it's not a magic panacea.
I suppose he could hire someone to do it for him but complaining on /. is just way easier ;-)
Re: (Score:2)
Re: (Score:2)
There's a cutoff where it's useful to say that "you can do it yourself." I *am* a programmer, and have been for 35 years or so. One thing that annoyed me -- "back in the day" -- was Evolution's spotty support for Palm Pilot synchronization. I was fiddling with Gentoo's portage versions of the program and the various libraries so much that I finally downloaded the source for Evolution, and started to look at where the code that governed this problem lived. I recall asking someone a question about the source
Re: (Score:2)
Also... As an open source contributor and also long time software developer, there's no end of things to sink my spare time into, but my spare time is already alloted to other projects (some of them open source)... Sometimes I just want to flop on the couch and watch TV but {mythtv,xbmc,plex} is broken in a way that prevents me from doing it... So yes, I might be capable of fixing it myself, assuming I could find the bug in source I don't know, figure out the correct fix, that isn't going to break a dozen o
Re: (Score:2)
Re: (Score:2)
How about releasing a version of bash that has function passing disabled.
People are using this feature and taking it away will break stuff. The latest update (not sure whether Apple already ships it) stores all function definitions with a prefix of BASH_FUNC_, and function definitions are disabled for all variables not starting with the prefix. This allows to retain the feature, but prevents the execution of malicious code at the same time.
Re: (Score:2)
Unless of course the malefactors know this and stick BASH_FUNC_ in front of their exploit strings.
Re: (Score:3)
Unless of course the malefactors know this and stick BASH_FUNC_ in front of their exploit strings.
This won't work because an attacker will only be able to manipulate the content of some environment variable, but not its name. And being able to manipulate arbitrary environment variables has always been equivalent to being able to execute arbitrary code. Think LD_PRELOAD or IFS, for example.
Re: (Score:2)
> an attacker will only be able to manipulate the content of some environment variable, but not its name.
How can this be true?
I just tried and successfully passed the variable "_BASH_FUNC_thingy" with the value "my_attack" through my apache web server to a CGI script using a url entered into a browser.
Re: (Score:2)
You mean like practically everyone's .profile
Re: (Score:2)
The profile is sourced after the bash shell has already initialised. If my understanding is correct, the exploits are triggered because bash parses the environment during initialisation.
Not sure if this is 100% correct, or if there is a difference in before vs after parsing, but if I am correct, this would not affect user profiles.
Anyone care to expand?
Re: (Score:2)
I think you are correct on this point, I was a little too quick. Still I suspect there would be issues; which people who make heavy use of the shell would 'feel'
Consider ssh->bash->screen->bash. The first bash will be a login shell that sources the profile, the second will be a subshell, and would no longer have the functions defined. Sure there are plenty of ways to 'solve' that problem but will certainly require some alterations to common work flows.
that was fast (Score:2)
only took them five days to fix from the disclosure [slashdot.org].
Re:that was fast (Score:5, Interesting)
Re: (Score:3, Funny)
Mac servers? You mean that SE/30 running the Pokeytalk network, with the Laserwriter attached to it?
Re: (Score:2)
Those do still exist. I saw a laserwriter at my local library hooked up to some ancient Apple box.
Re: (Score:2)
Re: (Score:2)
Not sure on the exact details of OSX DHCP handling (did not dig through it all) but no it was not vulnerable, based on a quick empirical test.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Papa's gonna buy me a diamond ring?
Re: (Score:2)
but if that sandbox can ping...
Papa's gonna buy you a diamond ring.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But they are not all in place, there was no mention in the apple security announcement of CVE-2014-6277 or CVE-2014-6278 being fixed...
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Bonjour is just Apple's implementation of Zeroconf. It's freeware, with the core components of it under the Apache licence.
Have a look through the code yourself "to be sure". https://developer.apple.com/bo... [apple.com]
Re: (Score:2)
Re: (Score:2)
Mac's don't get viruses. . . (Score:2)
. . . until they do.
With more Apple computers running in high-value commercial enterprises, one has to wonder why they are so lax about security.
Re: (Score:2)
Re: (Score:2)
The OS X BASH vulnerability patch is still not available as an automatic update whereas most Linux repositories had one available within 72 hours of the exploit. Studies of operating system security show that vulnerabilities in OSX persist the longest without being patched (assuming you discount big server OS's like Solaris) while Windows is patched the quickest. [1]
It shows a huge difference in attitudes, in my opinion. Microsoft is enterprise focused, so they take security vulnerabilities very seriously
Re: (Score:2)
- RedHat was the only linux distro in the survey that I saw
- The nature of the vulnerabilities that Microsoft typically patched was quite a bit different from those in the other operating systems studied.
I really doubt it's a difference in attitude. It could simply be that considering that considering their user base, Apple puts any patches through a much more rigorous testing than a linux distro typically does. They may (correctly) conclude that a rushed patch could do mo
Re: (Score:2)
1. I have seen no evidence that Apple has increased the speed of its patching of security vulnerabilities since the study was conducted (this latest patch delay being just one example). Do you have any evidence that Apple has changed?
2. Red Hat is the best-supported corporate Desktop Linux distro, so it makes since to use them as a base of comparison as opposed to something more consumer-oriented like Ubuntu.
3. Multiple other studies have show that Apple lags behind in fixing security flaws.[1] [2]
Do y
Re: (Score:3)
Your second source is not a study or report at all but the opinion of a guy selling security software. I'm not saying his opinion isn't worth anything, only that he stands to gain by scaring OS X users into buying his software. And just as an
Re: (Score:2)
It could simply be that considering that considering their user base, Apple puts any patches through a much more rigorous testing than a linux distro typically does.
Yeah, I was really pissed when RHEL released a patch for a kernel bug last week and it disabled the phone app on my iPhone. *#$^ing RedHat.
Re: (Score:2)
It could simply be that considering that considering their user base, Apple puts any patches through a much more rigorous testing than a linux distro typically does.
Yeah, I was really pissed when RHEL released a patch for a kernel bug last week and it disabled the phone app on my iPhone. *#$^ing RedHat.
Not exactly sure what you're trying to say but let me clarify my statement. Apple's users require more hand holding than RHEL users. I'm very serious when I say that Redhat's patch testing process may not be as rigorous as Apple's and I will add that because of the differences in user base, it doesn't have to be.
I wasn't slamming RedHat or linux at all if that's what you thought.
Re: (Score:2)
http://support.apple.com/kb/DL... [apple.com]?
This release contains improvements and bug fixes, including:
Fixes an issue in iOS 8.0.1 that impacted cellular network connectivity and Touch ID on iPhone 6 and iPhone 6 Plus
On their new flagship phones for iOS8. If Apple devs were really that thorough, I doubt that would have passed the first round of tests. On the other hand, I've noticed patches on RHEL take longer to release than Ubuntu which take longer than other Linux distros. But I'm not sure OSX is delayed due to rigorous testing.
Re: (Score:2)
I was making a reference to the recent Apple patch that disabled the phone on the iPhone. http://support.apple.com/kb/DL... [apple.com]?
This release contains improvements and bug fixes, including: Fixes an issue in iOS 8.0.1 that impacted cellular network connectivity and Touch ID on iPhone 6 and iPhone 6 Plus
On their new flagship phones for iOS8. If Apple devs were really that thorough, I doubt that would have passed the first round of tests. On the other hand, I've noticed patches on RHEL take longer to release than Ubuntu which take longer than other Linux distros. But I'm not sure OSX is delayed due to rigorous testing.
Because no linux distro ever releases a patch with bugs... right? ;-)
Anyway. I said the process might have to be more rigorous. I didn't say it was flawless. And the whole 8.0.1 debacle only adds to my point. A patch can sometimes do more damage that what it's trying to fix. Better to take a couple extra days to get it right than to get it out as quickly as possible but screw it up.
Re: (Score:2)
I'm sorry, but I can't get exited about two days to fix one vulnerability (Major Linux distributions) versus five days to fix most, if not all known vulnerabilities (Apple). The fix is there, and I'm glad they took the time to do some additional testing, especially because bash on Mac OS X is something that a large majority of users will not even run, and those that do will mostly only use it for their command line handling. Remote exploitation is just not possible with the default settings, so I don't car
Yosemite too now (Score:2)
The patch is irrelevant (Score:2)
Did anyone try to understand how this "bug" works?
Unless you have any service running, connected to the internet, that starts "bash scripts", nothing can happen to your computer.
Or how exactly do you think angel'o'sphere has any way (not chance! WAY!) at all to start a bash script on your computer, exploit the weakness and on top of that gain "super user" privileges?
That is not going to happen for any private mac user who has not running an Apache etc. and has not activated CGI scripts (and a router configu
Re:Exploit that only affects Mac and Linux (Score:5, Insightful)
At least it's still news when we learn about Mac and Linux vulnerabilities. :-)
Bashed. (Score:4, Insightful)
At least it's still news when we learn about Mac and Linux vulnerabilities. :-)
This is Bash, remember.
Stallman and the Free Software Foundation (FSF) considered a free shell that could run existing sh scripts so strategic to a completely free system built from BSD and GNU code that this was one of the few projects they funded themselves.
Bash (Unix shell) [wikipedia.org]
The beta was released in 1989. 25 years ago.
Which makes a perfect farce of the notion that many eyes make all bugs shallow.
Wrong on two counts (Score:2)
1) We don't know when the bug was introduced, although it's clear that it was quite some time ago.
2) I defy you to name any version of any reasonably complex software that is guaranteed to be free of exploitable bugs. It's been shown by people much smarter than me that it's mathmatically impossible to do so. (Just one example thread discussing the problem. [schneier.com])
The difference is that wit
Re: (Score:2)
The difference is that with OSS, they all will eventually get found and fixed. The same can't be said of closed source software.
... as long as the bug is unknown, no one will find it. Or is it your hobby to read OOS C code and "grasp it" and figure potential and true bugs, and on top of that: fix them?
That is nonsense. As soon as closed source software has a bug professionals are looking for the source of the bug and hence it gets finally fixed.
There is bottom line no difference
Which makes a perfect farce
Re: (Score:2)
Only the idiots claimed it was impossible. It was much more unlikely because Windows was designed at the time from the ground up to be backdoored. It was literally defective by design. It has come a long way and malware makers have also gotten much more sophisticated. A lot of them are users of linux and unix systems and naturally enough they now design for those systems as well. One reason is that the newer linux distros are not as security focused as the old days. People routinely log into a user a
Re: (Score:2)
I'm just saying a few years ago, we had an awful lot of that variety of idiot.
Re: (Score:2)
I wouldn't go that far. Windows installations routinely get reamed. It's better but I wouldn't call it secure. I've got a secure linux install on a seperate laptop for banking and such and it's locked down like Fort Knox. As I only use it for things I'm paranoid about I'd say it's pretty safe. I'd rather bet on it than Windows.
Re: (Score:2)
Yes but the problem is and has always been Microsoft does not really use the NT security model but instead "re-implements" lots of controls in upper layers. Those layers in the past tended to be running with pretty high NT model privileges (that has gotten much better).
Re: (Score:2)
Exactly. This is a problem Microsoft has had for several decades they lack mechanisms to generate internal consensus. So they build a capabilities based security model but then don't build all the tools and support that their user community will need to make it work so everyone just runs as admin. Then they tone it down and put a permissions based system in place. But that still has problems. Then they start tightening and then use sandboxing for yet another capabilities system...
Re: (Score:2)
This is the kind of thing people on the slashdot of yesteryear thought were impossible. Remember when people would post that Apple computers and/or Linux wasn't vulnerable like Windows?
No what people have said is that Windows was vulnerable in different ways than Linux or Unix. Viruses were/are a huge problem for Windows machines and largely a Windows problem. All machines can be compromised with a Trojan if the user allows it to run. Vulnerabilities affect all systems but Linux, Unix, and OS X are built differently than Windows.
No sensible person ever though it was impossible (Score:3, Informative)
But even here, again, when you look at a typical OS X desktop system, now many people:
1. Have apache enabled AND exposed to the public internet (i.e., not behind a NAT router, firewall, etc)?
2. Even have apache or any other services enabled at all?
So, in the context of OS X, it's yet another theoretical exploit; "theoretical" in the sense that it effects essentially zero conventional OS X desktop users. Cou
Re: (Score:2)
Re: (Score:2)
I like how slashdot are making out that this is more of an apple problem when perhaps 0.0001% of apple users are even running a web server and most of those are using php and not mod_cgi, the dhcp client is not vulnerable, etc.
Yet Linux with dhcp client vulnerable and a whole slew of other system utilities potential vulnerable due to using bash everywhere to glue tools together is given a pass.
bash still isn't fixed properly yet, and until it is, any linux box with a dynamic IP address sis potentially
Open Source is still better (Score:2)
Apple wouldn't have known about this little known old feature turned security hole if it wasn't for open source. Windows having similar holes, wouldn't benefit from other operating systems discovering common flaws in their code base!
Diversity of the many systems that use BASH also provides increased security. People on linux are going to think twice about risky things involving bash for a while now, while Apple had no such security issues because they jail and limit their DHCP client like freeBSD also doe
ridiculous (Score:2)
Billions of lines of code for decades and some security holes make you think that you have PROOF open source does not work? Foolish.
The discovery of this is proof that many eyes DO find problems--- Apple could have done it themselves and it could have gone forever not being discovered. Apple has hardly ANY code that old and don't think that newer code is somehow automatically better than old code.
How can you possibly think that something that wasn't noticed by all those people for decades is somehow the
Re:Exploit that only affects Mac and Linux (Score:4, Insightful)
It's a ticking time bomb, and this is likely just the blasting cap going off.
So you're expecting an 'explosion' even worse than Shellshock and co?
I doubt it. Bash will be hammered on, and will be made more secure, in the coming weeks.
Re: (Score:2)
Sure, but how many server administrators are going to actually update? Linux has a reputation of updates breaking builds and I suspect a lot of budget server administrators don't touch the updates on their Linux boxes once they go live for fear of borking them.
Re: (Score:2)
Passing functions on environment variables is a feature, executing code after the function definition is parsing error.
As the article states is was never documented, and after trying really hard can't think of legitimate reasons to do it when there is a defined documented method for executing statements in the subshell via arguments "-c"
Which is not say, it was never done via someone doing some "clever" programing but if it was it probably was not a "good idea"
So no I think its bug, and a bit dishonest to t