Apple Yet To Push Patch For "Shellshock" Bug 208
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.
~/.cshrc (Score:4, Funny)
Is there anything I should add to my ~/.cshrc file to protect against this bug?
Re:~/.cshrc (Score:5, Interesting)
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:
Re: (Score:2)
Re: (Score:3)
"Oh, you think you're kidding ... but the problem isn't just bash ... it's that Apple uses bash in place of sh."
A long time ago I used a non-Intel version of MacOSX that had tcsh as the default shell. So the parent might not be joking if .cshrc was part of the tcsh installation (tcsh has its own config .tcshrc but also reads .cshrc). If that's the case, well, none of the c-shells suffer from this bug. I wonder why Apple made the change. tcsh is BSD licensed as it's (or was) the default NetBSD (FreeBSD?) she
Re: (Score:2)
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.
Re:~/.cshrc (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2, Funny)
Yeah a better operating system than OSX.
I've used every OS on the planet (Score:2)
OSX is my favorite, second to Linux. But honestly, it's isn't that close.
Re: (Score:2, Interesting)
"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.
Paging Dr. House (Score:3)
Dunno about the OP, but I've to, due to job, from time to time. It's a bit like jail, with soft, white round corners. It gives me the jeebies, and I'm always grateful to return to my Debian box (FVWM, by the way).
So yes, I have, and never enjoyed the experience.
---------
Ah, now we've got it:
Separation anxiety disorder of childhood
F93.0 is a billable ICD-10-CM code that can be used to specify a diagnosis.
Clinical Information:
Anxiety experienced by an individual upon separation from a person or object of particular significance to him.
Re:~/.cshrc (Score:5, Interesting)
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: (Score:2)
Scripts that start with #!/bin/sh but are written dependant on bash features will fail. .
And that is just brain-dead from the beginning. If you ask for /bin/sh, you should get /bin/sh (which in my world should be statically linked, and I am looking at you, Linux distros) and not some almost-but-quite-not sh.
Re: (Score:2)
True, but if you are symlinking /bin/bash to dash, then you will break scripts that explicitly asked for bash.
Re: (Score:2)
True, but if you are symlinking /bin/bash to dash, then you will break scripts that explicitly asked for bash.
But that is so idiotic.
Why would anybody in their sane mind do it??
Re: (Score:2)
This is overgeneralized. A script looking for bash will fail if, and only if, it's calling bash specific features that doesn't exist in the linked shell.
Surely those bash specific entities are used and exist for a reason, but the _majority_ of scripts calling bash don't care what SH derived shell they have because they don't use the bash specific features. They call bash for convenience only.
Example, take every script in my /etc/init.d/ directory and there are zero bash specific features being called.
Re: (Score:2)
First of all, do you run your Mac as a server? If the answer is no then you most likely don't need the patch anyway. The MacPorts binary will depend on libraries installed by MacPorts, there's nothing wrong about that.
Stallman would be proud (Score:4, Insightful)
the gpl is doing its job of preventing commercial software from benefiting from it.
Re: Stallman would be proud (Score:3, Insightful)
Re: (Score:2)
"more secure?" Have you been paying attention?
As for having the "users interest" in mind, I'm not so sure about that either. Commercial software has a whole different idea of what the user's interest is. Apple and Microsoft think it's what the user is willing to pay for. That view is not entirely wrong. Google thinks that the user's interest is whatever the user expresses any interest in.
None of them are very prone to thinking about what is in the user's BEST interest. I think they don't feel entirely
Re: (Score:2)
They make their $$$ off the hardware that is handsomely marked up.
But thanks for trying!
Oh, and Google
You have potential, young Skywalker, but your comments clearly prove a Jedi, you are not.
But you will be someday
Re: (Score:2)
Apple isn't into commercial software.
They make their $$$ off the hardware that is handsomely marked up.
What do you call Aperture, Logic Pro, Final Cut, Mainstage, Compressor and Motion?
What's the difference between a Mac and a PC if it's not commercial software?
What's the difference between an iPhone and an Android phone if it's not commercial software?
What is Mac OS and all the apps that come with it if not commercial software?
You seem confused about what it is that differentiates Apple's products.
Re: (Score:2)
You have potential, young Skywalker, but your comments clearly prove a Jedi, you are not.
You're right. I'm not a member of your religion.
But you will be someday ...
Don't hold your breath
Re: (Score:2)
Bollocks.
MS famously invented the notion of "a best practice". Unfortunately they seem incapable of following good practice in many areas. The other vendors you mention also have similar foibles regarding what's best for you.
Now the FOSS community is just that - a community filled with opinions, advice and a fair old software output.
Each product stands on its own. You pays your money ...
Cheers
Jon
Re:Stallman would be proud (Score:5, Insightful)
Moron: Yeah I wanna redistribute your software but not abide to the license it comes with it, because it's not freedom enough! I mean, give my source modification to everybody who asks? Avoid patenting and so effectively closing up the work you intended for the world? Why should I do that?
Dev: how about you write your own damn code and license it as you please? And I suppose you are perfecly fine when your own licenses are being ignored?
Re: (Score:2)
Or we'll just do our best to not use software under licenses that cause us trouble.
Re: (Score:3)
Maybe some day Apple will smarten up and move to next to Stanford and Berkeley so they can buy some coding talent and be able to patch these kinds of things.
Until then, they will be at the mercy of the GPL v3.
[Either that or how the hell can this even be exploited on a Ma
Re: (Score:2)
Partial output from running "man bash" on my Mac:
COPYRIGHT
Bash is Copyright (C) 1989-2005 by the Free Software Foundation, Inc.
By the way, betwixt means between.
Re: (Score:2)
Actually, Apple uses an old version based on Bash 3.2 which is under GPLv2. Not really a problem, patches exist for as old as Bash 2.0.
Re: (Score:2)
Patches for 3.x bash versions? (Score:2)
Aren't there shellshock patches available for the non-GPL 3'd versions of bash?
Re: (Score:2)
Redhat has patched the bug right down to RHEL 4, which has bash 3.0 which is even lower than Apple's bash version:
https://access.redhat.com/arti... [redhat.com]
Since it's GPL I suppose Redhat has already released the source code for their GPL-2 bash versions at the same time as the installable binary updates?
Stackexchange has discussion on patching yourself (Score:5, Informative)
Re: (Score:2)
Stackexchange has a link for anyone who wants to patch their own servers... I've been following it here: http://apple.stackexchange.com... [stackexchange.com]
Does this work fine with Snow Leopard does anyone know?
Re: Stackexchange has discussion on patching yours (Score:3, Informative)
Yes - I have a machine which I patched with this method. But then I created the question and answer as well as my blog at http://alblue.bandlem.com where I've been writing about it, and at http://www.infoq.com @alblue
Re: (Score:2)
Re: (Score:2)
I'm going to find out. I may test on Leopard as well (since I still have a quad G5)
Re: (Score:3)
Confirmed that it works on Snow Leopard.
Bash a bad fit for osx (Score:3, Insightful)
Re:Bash a bad fit for osx (Score:5, Informative)
Initial versions of OS X did come with zsh instead of bash, they only switched later (but before there was any talk of the GPLv3). They reason they switched was for compatibility, as many packages expect /bin/sh to be bash (yes, they're technically broken, but that doesn't help end users that want to use/compile them).
Re: (Score:2)
That's getting less common since Debian and Ubuntu no longer have bash as /bin/sh. There are still packages that expect that, but they now don't work on Debian, Ubuntu, or the BSDs, which starts to make it more likely the authors will care about fixing them.
Re: (Score:2)
Probably good to give another 48 hours anyway (Score:5, Insightful)
Some systems should be patched asap, of course, and we've patched our most critical systems. However, the bash team is still working out the best way to do a comprehensive fix, one that takes care of related issues as well as the initial exploit. As of Friday evening Red Hat and upstream bash were headed in two different directions. We'll be waiting until probably Monday evening to patch most of our systems, even the bash team decides what they're going to do and that gets implemented in rpms. It's not unreasonable for most OSX users to take care of it Monday or so, especially since most Macs don't have a public facing internet presence.
If you're using OSX for an important public facing web server, you can update it today via configure; ./make; make install
Re: (Score:3)
In the mean time, for those who care enough to already be running mod_security. All hits to our multiple web servers go through a mod_security reverse-proxy first:
## Bash attack
SecRule REQUEST_HEADERS "^\(\) {" \
"phase:1,deny,id:1000,t:urlDecode,status:403,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule REQUEST_LINE "\(\) {" \
"phase:1,deny,id:1001,status:403,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule ARGS_NAMES "^\(\) {" \
"phase:2,deny,id:1002,t:urlDecode,t:urlDecodeUni,status:403,log,msg:'CVE-2014-6271 -
Is it actually a bug at all? (Score:5, Insightful)
Once upon a time, I learnt that one should not make setuid-root sh scripts, exactly because the shell has so many unpredictable ways to make your script unsecure and because secure input validation inside shell scripts itself is nearly impossible. So why do we have the situation now, that internet services are calling bash scripts to run as root with data input from the internet without proper validation?
In other words: It's no wonder that bash is still 'vulnerable' after two patches, because it isn't supposed to be used like this. And the remaining problems are not a bug in bash, but wrong usage of bash.
Re: (Score:2)
So why do we have the situation now, that internet services are calling bash scripts to run as root with data input from the internet without proper validation?
Because everyone forgot how insecure unix-likes were when windows joined the internet.
Take a look at the old CERT advisories and you will see exploit after exploit specifically via command-line shenanigans.
Re: (Score:2)
Re: (Score:2)
At least. I remember the original "Morris worm" which took advantage of default setups that were wildly insecure by any modern standard.
Re: (Score:2)
Yes, it is a bug. The shell shouldn't be evaluating expressions inside a quoted (or unterminated for that matter) string.
The whole function exporting mechanism is a bug (Score:2)
The whole idea of inspecting the contents of arbitrary variables is a bug. Variables can contain any data the user chooses, and the fact that it happens to look like a function definition is none of the shell's business. Bash should have defined a single variable for the purpose in which all the function definitions are packaged up, or at least have defined a class of variables (e.g. BASH_FUNCTION_*) for the purpose.
Re: (Score:2)
It doesn't have to run as root. Even httpd user identity is powerful enough to call ps and check /tmp and all sorts of stuff for further discovery of vulnerability.
While an ideal system provide several layers of security and prevention mechanism against exploits, the average web application developers are either idiots who are completely ignorant of security-related issues (ex: SQL injection) or underpaid labors who just don't give a shit about it (I did that too, blame the customers I don't care), and thei
Re: (Score:3)
I'd heartily agree with the above remarks.
To be honest, using bash for running scripts, especially on something public-facing like a web server, is just driven by laziness and stupidity. Most scripts would run perfectly fine on a lightweight shell without all of bash's features.
If you are talking an embedded system or even a dedicated server, I really don't understand why you'd want (or need) bash on your system at all. For that matter, for a lot of embedded systems I know there is no good reason to have a
Forget Apple engineers, use NetBSD's patch (Score:5, Informative)
The smartest thing to do right now is to not expose a buggy 25-year-old parser to any random person on the internet. Just disable function importing from the environment by default and put it behind a flag.
Here is a BSD-licensed patch for it: http://seclists.org/oss-sec/20... [seclists.org]
You're welcome.
Use Macports (Score:4, Insightful)
Macports updated their version of bash. Get macports here, if you don't already have them, and install bash: https://www.macports.org/ /bin and remove original Mac binary.
Make sure to move their bash into
Re: (Score:2)
Also make sure to remove /bin/sh, because (at least on my Mac, and I'm fairly certain I haven't screwed around with /bin) rather than have /bin/sh be a symlink or a hard link, /bin/sh is a copy of /bin/bash. Not sure why.
Homebrew anyone? (Score:2)
Re: (Score:2, Offtopic)
I'd be interested to hear why the down modder thinks my points above are trolling. Can you actually defend the FSF statement as written? Is it not a poor and flawed blanket statement? What are your arguments in support of it? Or did I just hit a nerve?
Re: (Score:2, Insightful)
You conflicted with their ideology and got a "-1 makes me uncomfortable" mod.
Re:Issue with FSF statement... (Score:5, Informative)
Specifically what in your opinion is inaccurate about the following statement.
'Everyone using Bash has the freedom to download, inspect, and modify the code -- unlike with Microsoft, Apple, or other proprietary software.'
Microsoft contributes to certain open source projects while at the same time extorting revenue from Android handset makers under threats of litigation. As such its support of openness is suspect.
Re: (Score:2)
He has no answer to that, and neither do the micro softies and apple corps who mod'ed him up.
Apple v. Apple (Score:2)
neither do the micro softies and apple corps who mod'ed him up.
Apple Corps? What do the Beatles have to do with this?
Re:Issue with FSF statement... (Score:4, Insightful)
The fact that its a blanket statement makes it inaccurate, when I can use and contribute to Katana, Kudu, Entity Framework, Asp.Net MVC, Helios, WebAPI, vNext and a host of other things on the MS side, or LLVM and others on the Apple side. Microsoft support of open source is the same as Gnu and FSF - they both support their own pet things and ignore hosts of other things.
Patent license revenue is entirely an aside to this and has fuck all to do with the point at hand. Just because you are an open source project doesn't make you above patent law.
MS patented "open", funky licenses (Score:5, Insightful)
> There can no be any 'suspect' in the 'openness' because they have agreed to the license
In some cases, such as document formats, they have patents that apply. The _copyright_ license means you're not violating their _copyright_ by using/modifying/distributing the code, or code that has a similar function, but you're still subject to theor patents, so they can still sue you for millions and billions of dollars. The only protection you have for this code (and any code that reads or writes their format) is an informal promise that as long as they don't mind what you're doing, this year they won't sue you. That's certainly suspect. They might not completely screw everyone who touches their code, but they've reserved the right to do so.
They also have a license which they call "open", but it sure doesn't read like any open source license before. "Hi, my name's Chelsea", their license purrs, with her adam's apple rising. Suspect.
Re: (Score:2, Redundant)
Huge collections? Where's the source for Windows, Office or OS X. I know they have open source projects but their main products are exactly as the FSF has stated.
Re: (Score:3)
I don't see the full source for OS X on there funnily enough which was my point. Point me to the full source of Windows or Office or SQL Server.
Re: (Score:2)
The BSD layer is pretty IRRELEVANT to the average user.
To the typical person wandering around the Apple Store, it is the OpenStep layer that is the OS. Those people will never be aware of or interact with the BSD layer EVER. For them, the GUI is the OS.
That is perhaps the most important aspect of this situation for normal Mac users. They don't have to worry about bash because it's invisible and irrelevant.
Re: (Score:3)
Open source is pretty IRRELEVANT to the average user. They want something that lets them run Word and look at Facebook. To anybody with the technical ability to make use of the source, the open parts of OS X are the important ones. Not having the source code to your window manager isn't the end of the world. For example, this situation - the vulnerability is in the open source part, so you can go ahead and patch it yourself.
Re: (Score:3)
Re: (Score:2)
Says the tantrum-throwing Apple fanboi.
Re: (Score:3)
I don't see the full source for OS X
http://opensource.apple.com
I don't see anything related to Quartz or Cocoa on this page [apple.com]. So I don't see how this is full source.
Re:Issue with FSF statement... (Score:5, Informative)
This comes across as scaremongering, as its a blanket statement professing the openness of bash compared specifically to Microsoft and Apple, while both those companies have huge collections of open source projects where I can do just what they are trumpeting with Bash and the GPL.
Its a perfect example of why blanket statements should be studied very carefully before being used, as it can just distort your perceived stance when people call you on the flaws of your statement.
Apple open sources [apple.com] large portions of their OS X operating system including, it seems, the version of BASH [apple.com] they include with it. Using that website I was able to download the source code for their VPN daemon (same one used on Linux), patch it, compile it and install it in on my mother's MacBook to allow her to connect to a Microsoft VPN server that was sending malformed greeting strings. With Aqua you are unfortunately out of luck since it is closed source. With Windows you are not just out of luck ayoure _shit_ out of luck since the whole thing is closed source, unless you are a major foreign government. They get the rare privilege of doing their own code reviews.
Re: Issue with FSF statement... (Score:5, Insightful)
It's true, Apple releases the full source code to the UNIX underlying MacOS X, including all the user land command line utilities and the OS kernel. You can rebuild them all.
So what is this article about?? Things are working exactly like FSF intended. Apple users can download the source to bash, patch it, and install it on their own machines. If people wait for the vendor to patch, what's the difference between it and closed source?
Re: (Score:2)
It's true, Apple releases the full source code to the UNIX underlying MacOS X, including all the user land command line utilities and the OS kernel. You can rebuild them all.
So what is this article about?? Things are working exactly like FSF intended. Apple users can download the source to bash, patch it, and install it on their own machines. If people wait for the vendor to patch, what's the difference between it and closed source?
I actually patched the source code of that OS X VPN daemon with a patch I got from the bug tracking system of a Linux distribution. The whole process took an hour and by far the most of that was spent figuring out how to compile the damn thing.
Re: Issue with FSF statement... (Score:2, Interesting)
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: (Score:2)
Your average Apple user has downloaded/installed zero bash updates in the last 48 hours unless they first downloaded/installed 2.5GB of Xcode WTF. Even then they only got the same patches developed by the OSS/bash dev community.
Re: (Score:2)
Ahem. Apple is legally compelled to issue source code for whatever version of bash they use. It's called the GPL. For the rest of their core operating system (but not the proprietary GUI), yes, Apple voluntarily has released source code. It's mostly derived from BSD licensed stuff, and nothing compelled them to do so.
It is entirely possible to run bash on Windows, too. I'll let you figure out how. And the provider of that bash is compelled to make their source code available too.
Re: (Score:2)
Ahem. Apple is legally compelled to issue source code for whatever version of bash they use. It's called the GPL. For the rest of their core operating system (but not the proprietary GUI), yes, Apple voluntarily has released source code. It's mostly derived from BSD licensed stuff, and nothing compelled them to do so.
It is entirely possible to run bash on Windows, too. I'll let you figure out how. And the provider of that bash is compelled to make their source code available too.
Wooosh! The OP made the rather sweeping claim that:
Everyone using Bash has the freedom to download, inspect, and modify the code -- unlike with Microsoft, Apple, or other proprietary software.
Which covers a bit more than just BASH, he made the mistake of claiming that OS X is entirely closed source which it demonstrably is not. You can patch a bug in the VPN daemon in OS X yourself, now try doing that with the corresponding Windows component. You can do the same with a bug in the version of BASH used by OS X, fix the bug, patch the code, compile it and install it on your OS X box. Now care to try and patch a bug like this in the native Windows
Re: (Score:2)
The OP you mention is actually the FSF.
It doesn't change much but its pretty easy to get access to the Windows codebase if you work at a university, and you can submit bug fixes.
Re: (Score:2)
The difference between Savage Rabbits post and the FSFs statement is that the above post isn't a blanket one.
Re: (Score:3)
The difference between Savage Rabbits post and the FSFs statement is that the above post isn't a blanket one.
What is the FSF complaining about anyway? That Apple is hesitating to adopt their GPLv3 licensed version? Then Apple is a member of a large crowd that apparently includes Linus Torvalds who also has reservations about using GPLv3. Meanwhile Apple's version of BASH is freely downloadable and user modifiable which AFAIK is what the FSF wants. While it is certainly true that Apple should have quickly pushed a patch for this problem the FSF made a blanket statement that just isn't true.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
It's a stupid statement anyway. OS X is partly open source and partly closed. The bug is in the open source bit. So just download a patched version of bash, compile it, and install. Problem solved, just like you could do with any open source OS. People have even written a bunch of scripts to do the whole thing for you.
Re:Issue with FSF statement... (Score:4, Informative)
OK, here's [apple.com] the full source to Apple's version of bash, and here [apple.com] is the source to the entire open part of OSX, including the XNU kernel.
Now YOU shut the fuck up, you clueless knuckle dragging cowardly fool,
Re:Issue with FSF statement... (Score:4, Informative)
OK, here's the full source to Apple's version of bash, and here is the source to the entire open part of OSX, including the XNU kernel.
Just noticed with surprise that linking to Apple open source code is apparently "flame bait".
Re:Ars Technica speculates? (Score:4, Informative)
Re:Ars Technica speculates? (Score:5, Informative)
What are you talking about? It is completely factual and a valid point. Apple currently bundles 3.2.51, which is licensed under GPLv2. The patched version of bash is the new 4.3.25, which is licensed using GPLv3. Including it would change the license they are using, which I imagine takes some consideration.
Here are patches for Bash 3.2:
https://ftp.gnu.org/gnu/bash/b... [gnu.org]
https://ftp.gnu.org/gnu/bash/b... [gnu.org]
Re: (Score:3, Informative)
This is nothing more than anti GPL FUD. I mean how did Apple manage to originally bundle BASH without contaminating Mac OS X with the GPL 'viral' license. Shame on Ars Technica for spreading this FUD further. Since when has slashdot become a platform for spreading anti-GPL propaganda?
Excuse me, but there is no "anti GPL FUD" or "anti-GPL propaganda". Apple doesn't want to touch GPL 3 licensed code, and quite rightfully so.
Re: (Score:3)
So anyone not agreeing with your ideology is a sociopath? Don't you get the irony in that?
Re: (Score:3)
Ah, propaganda!
GPLv3: "code should be open and free, unless we decide that the freedom that a company chose was not the freedom we wanted them to choose!"
So, you think idea that you can do anything you want within the terms of the licence is a "loophole". Mhhmmm.
Oh, and let's not forget the idea that anyone who disagrees with your position is a sociopath.
What next? The test for sociopathic tendencies involves presenting a choice of OSS licences and if the subject picks anything other than GPLv3 they get bra
Re:Ars Technica speculates? (Score:4, Funny)
The GPL v4:
You may not modify, distribute, publish, compile, share, view or in any other way make use of this source code without the express written permission of Richard M. Stallman. This is for the protection of your freedoms, comrade!
Re: (Score:3)
Re:Ars Technica speculates? (Score:5, Informative)
The version of Bash with the patch is v3, the version Apple uses is v2. They're perfectly happy to ship GPLv2 code (quite a bit of their codebase is GPL), but they have strenuously avoided GPLv3 where possible.
What is hard to understand about this?
That, plus the fact that the patches issued so far are not 100% effective is probably why there is no official patch from Apple yet (you are free to compile your own of course).
They have stated that they are working on it, so it will be forthcoming soon enough.
Re: (Score:2)
The GNU project shipped officicial patches for all GNU Bash versions going back to 3.0, and I've seen other people patch versions going back to 2.0.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But it is part of the ports collection, which is managed by the FreeBSD project and that a lot of FreeBSD users use.
Re: (Score:2)
The installed binaries built from the ports tree are not automagicly updated with the standard OS patches, this is why many people chose NOT to build from the ports tree and instead chose to use the binary package installer pkg tool such that the packages are then updated automaticly by the FreeBSD team as opposed to the user having to re-fresh the ports tree and manulay rebuild every package that gets an update.
I call bullshit. Binary packages have never been up to date on FreeBSD. Anybody knows anything about FreeBSD knows to use the ports tree. Especially for something that takes 2 seconds to build. The ports tree since yesterday has had the NetBSD workaround which is even safer than GNU's own since it disables the vulnerable (and hardly used) functionality entirely. (Who intentionally imports shell functions from the environment?) While we're going to be updating our Linux systems yet again for GNU's next attem
Re: (Score:2)
Correct. For this to be exploited, bash needs to be spawned by an internet facing service and pass environmental variables into a bash shell. Nothing on OS X does this by default. OS X does not run the open source dhcpd, and is thus not exploitable via dhcpd, and does not run apache unless manually enabled, and manually configured to run mod_cgi. Remote ssh is also not enabled on the mac by default.
Far more vulnerable is Linux which runs dhcpd on any machine with a non-static IP, through which bash i
Re: (Score:2)
There are users using it, and it is documented.