Apple Yet To Push Patch For "Shellshock" Bug

~/.cshrc by Bing+Tsher+E · 2014-09-27 00:31 · Score: 4, Funny

Is there anything I should add to my ~/.cshrc file to protect against this bug?

Re:~/.cshrc by oneiros27 · 2014-09-27 00:35 · 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:

csh< env x='() { :;}; echo vulnerable' perl -e 'system "echo test;"'
vulnerable
test
csh>

--
Build it, and they will come^Hplain.
Re:~/.cshrc by koan · 2014-09-27 00:51 · Score: 2, Funny

Yeah a better operating system than OSX.

--
"If any question why we died, Tell them because our fathers lied."
Re:~/.cshrc by lippydude · 2014-09-27 01:14 · Score: 1

Rename /bin/bash to /bin/bash.bak then create a link from /bin/dash to /bin/bash ..
Re:~/.cshrc by fnj · 2014-09-27 01:52 · Score: 4, Interesting

Rename /bin/bash to /bin/bash.bak then create a link [cyberciti.biz] from /bin/dash to /bin/bash ..
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:~/.cshrc by itsenrique · 2014-09-27 04:15 · Score: 1

Posting to undo accidental moderation, darn tremor.
Re:~/.cshrc by aNonnyMouseCowered · 2014-09-27 04:22 · Score: 2

"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?) shell. Are there any OSX services that actually depend on some bash bug/feature not implemented in say, tcsh, zsh or any of the other permissively licenses shells?
Re:~/.cshrc by smash · 2014-09-27 04:23 · Score: 1

Linux also uses bash in place of sh in most distributions. Linux also uses a dhcp daemon which is vulnerable to being used to exploit this bash bug. OS X does not.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:~/.cshrc by Concerned+Onlooker · 2014-09-27 04:48 · Score: 1, 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.

--
http://www.rootstrikers.org/
Re:~/.cshrc by Alan+Shutko · 2014-09-27 05:29 · Score: 1

True, but if you are symlinking /bin/bash to dash, then you will break scripts that explicitly asked for bash.
Re:~/.cshrc by kthreadd · 2014-09-27 05:33 · Score: 1

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 by kthreadd · 2014-09-27 05:36 · Score: 1

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.
Re:~/.cshrc by ThePhilips · 2014-09-27 05:44 · Score: 1

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??

--
All hope abandon ye who enter here.
Re:~/.cshrc by hcbecker · 2014-09-27 06:43 · Score: 1

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:~/.cshrc by s.petry · 2014-09-27 08:28 · Score: 1

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.

--
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Re:~/.cshrc by Anonymous Coward · 2014-09-27 09:44 · Score: 1

By "most distributions" you aren't including debian and ubuntu. Which use dash. Fedora can use dash, but most people don't set it by default.
Since pipe() uses /bin/sh, and useful system programs like dhclient are using pipe() means that you are better served running a small, simple and hopefully exploit-free shell as /bin/sh.
Re:~/.cshrc by donaldm · 2014-09-27 16:47 · Score: 1

Rename /bin/bash to /bin/bash.bak then create a link from /bin/dash to /bin/bash ..
Why on earth do you want to do that? If you are running a Rehat distribution on a production machine that is a great way to get fired unless you have the appropriate change requests filled out and even then you would have to install dash which adds an extra level of complexity.
On Fedora 20 as per two days ago:

> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

This is with "bash-4.2.48-2.fc20.x86_64" which does not require a reboot, although if you are like me the latest updates did contain a kernel update as well which does require a reboot.

So at least the latest release of Fedora is patched. As is Redhat 4 thorough 7 see here.

--
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
Re:~/.cshrc by Zenin · 2014-09-27 16:57 · Score: 1

It makes sense, /bin/csh was the traditional default shell of BSDish systems.
But the default shell doesn't matter, because the default shell isn't used by C library functions like system(). /bin/sh is used, no matter what your "default shell" is set to. And some foolish folks decided to go ahead and replace /bin/sh with bash.

--
My /. uid is better then your /. uid
Re:~/.cshrc by RoLi · 2014-09-27 18:13 · Score: 1

Because somebody on Slashdot told them?
Re:~/.cshrc by Kiwikwi · 2014-09-27 20:40 · Score: 3, 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:~/.cshrc by Kalium70 · 2014-09-27 21:18 · Score: 1

Apple's Software Update says that my system is up to date, but your code still results in "vulnerable" being printed.
Re:~/.cshrc by kthreadd · 2014-09-27 22:51 · Score: 1

Indeed, I just pointed it out as an easy to understand example.
Re:~/.cshrc by TheRaven64 · 2014-09-28 00:00 · Score: 1

I've run all of the updates on OS X and I still got the vulnerable message. A couple of days after the bug was public and the patches were available, I grabbed the source from opensource.apple.com, applied the FSF patches (which required some manual intervention, as they didn't apply cleanly) and recompiled. I'm now running a patched bash that isn't vulnerable, but it's not the one that Apple supplied.

--
I am TheRaven on Soylent News
Re:~/.cshrc by Jappus · 2014-09-28 07:30 · Score: 1

> And some foolish folks decided to go ahead and replace /bin/sh with bash.
Have you ever taken a look at the original Bourne Shell code? All the way up to V7, this header file was applied to each and every line of source code of the original Bourne Shell:
http://minnie.tuhs.org/cgi-bin...
Essentially, this header turned C into a really crummy version of ALGOL -- and the source code was written with that in mind. It took them until 1984 to de-ALGOLize the source code, and it was still a horrible mess after that.
So the Bourne-Again Shell (Bash) was created in 1989 as a response to the shoddy code (and other limitations). Then, when that one bloated out of control, people started going back to the "minimal Bourne Shell" approach in the modern incarnations of Ash and Dash; but by then, Bash had already become the de-facto replacement for Bourne Shells.
In the end though, for any nasty bug you find in Bash, you'll probably find two in the original Bourne Shell --- only hidden behind virtually unreadable source code.
And it is very likely, that nasty things lurk in tcsh, ksh and others. After all, as someone sage once said: "Any non-trivial program that consists of more than three lines of code has at least one bug."
Re:~/.cshrc by rs79 · 2014-09-28 10:53 · Score: 1

Has anyone confirmed sh and csh (et al) don't have this problem? In all versions?
Am I crazy in thinking that a CGI program, say, written in C, that gets environment variables from Apache should not have any local environment variables tossed to any program it wants to run. Those are in appropriate and are from a CLI context and do not apply here. They should be nulled as soon as the program realizes its running in a web context and not from a CLI.
Actually even better would be to replace system() with a function that blew up that workstation to weed out the lazy programmers.

--
Need Mercedes parts ?
Re:~/.cshrc by lippydude · 2014-09-28 11:01 · Score: 1

> Why on earth do you want to do that?

On the Internet, if you want the correct answer, first post the wrong one ...
Re:~/.cshrc by jeremyp · 2014-09-29 00:04 · Score: 1

You're probably not running a bash that isn't vulnerable. Neither of the first two patches completely fixed the issue. Personally, I don't think it'll be completely fixed until somebody patches bash to not interpret any of its environment variables as functions.
Which it should never have done in the first place.

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Re:~/.cshrc by TheRaven64 · 2014-09-29 01:56 · Score: 1

The second vulnerability is a lot harder to exploit. Most vulnerable things only allow attackers to set specific environment variables. If you can set arbitrary ones, then setting things like PATH or LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on OS X) are already exploitable, at least for privilege escalation.

--
I am TheRaven on Soylent News

Stallman would be proud by Anonymous Coward · 2014-09-27 00:31 · Score: 4, Insightful

the gpl is doing its job of preventing commercial software from benefiting from it.

Re: Stallman would be proud by frikken+lazerz · 2014-09-27 02:25 · Score: 3, Insightful

Stallman is batshit insane though, and doesn't even come close to representing the average FOSS user. That would be like thinking all liberals are like Michael Moore or all conservatives are like Rush Limbaugh. The average FOSS advocate just wants his software to work. He prefers FOSS because it is more secure and has the user's interests in mind, unlike software like iTunes that tries to sell users stuff or Chrome that tracks you and sells your data to the highest bidder. The average FOSS user doesn't care if there are binary blobs and doesn't mind using Adobe's Flash because it's way better than any of the open alternatives. This is also the reason Ubuntu and Mint are so popular, not GNUSense or whatever other totally free alternative he recommends. Tl;dr, Stallman shouldn't and represent the FOSS community, and although his ideas might be good in principle, the average user just wants his software to work on par or better than what he used to use on Windows.
Re:Stallman would be proud by marcello_dl · 2014-09-27 03:42 · 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?

--
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Re: Stallman would be proud by __aaltlg1547 · 2014-09-27 03:58 · Score: 1

"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 competent to judge.
The FOSS community has very definite opinions about what's in the user's BEST interest, and they tell you what it is and try to enforce it.
And I don't know if their idea of what's in my best interest is in my best interest.
Re:Stallman would be proud by armanox · 2014-09-27 04:05 · Score: 1

Or we'll just do our best to not use software under licenses that cause us trouble.

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Re: Stallman would be proud by TrollstonButterbeans · 2014-09-27 04:17 · Score: 1

Apple isn't into commercial software.

They make their $$$ off the hardware that is handsomely marked up.

But thanks for trying!

Oh, and Google ... ha! ... well ... Stanford pledged to not do privacy research with Google grant money, so you can read between the lines. Google's interest aren't the same as the "user's best interest" if it conflicts with advertising or privacy.

You have potential, young Skywalker, but your comments clearly prove a Jedi, you are not.

But you will be someday ...

--
Priest: "Universe from nothing, no laws of physics, sped up time"+ huge discrepancies. Creationism? No. Big Bang Theory
Re:Stallman would be proud by TrollstonButterbeans · 2014-09-27 04:23 · Score: 2

I'm sure that Apple, with $160 B in the bank, and developers writing entirely new programming languages like Swift are betwixt --- just betwixt!!! --- at the things the open source community can write in code that they can't figure out!!

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 Mac, sigh ...]

--
Priest: "Universe from nothing, no laws of physics, sped up time"+ huge discrepancies. Creationism? No. Big Bang Theory
Re:Stallman would be proud by smash · 2014-09-27 04:26 · Score: 1

Well.... not really. All i've had to do is ensure I am not running apache or open ssh on my macs. I'm not. Meanwhile anyone running Linux with dhcpd is vulnerable until they fix bash. On my FreeBSD servers I just uninstalled bash. Job done. This bug was fixed in sh about 30 years ago apparently according to twitter.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:Stallman would be proud by Concerned+Onlooker · 2014-09-27 04:40 · Score: 1

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.

--
http://www.rootstrikers.org/
Re:Stallman would be proud by kthreadd · 2014-09-27 05:38 · Score: 1

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: Stallman would be proud by __aaltlg1547 · 2014-09-27 09:37 · Score: 1

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: Stallman would be proud by __aaltlg1547 · 2014-09-27 10:00 · Score: 1

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: Stallman would be proud by JSG · 2014-09-27 11:01 · Score: 1

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 by Uberbah · 2014-09-28 15:57 · Score: 1

Why are those two always equated? Is MM a racist
Yes
I figured the response to this would have been partisan butthurt, just not something this lazy. How is MM a racist, etc.

So you agree with Rush that communists are the voice of the Left?
So you're a wingnut that wouldn't know a real leftist if he came up and slapped you in the face while singing Le IInternationale? Today's elected Democrats are to the right of today's Republican voters on just about any issue you can name.

Issue with FSF statement... by Richard_at_work · 2014-09-27 00:34 · Score: 1, Insightful

Everyone using Bash has the freedom to download, inspect, and modify the code -- unlike with Microsoft, Apple, or other proprietary software.

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.

Re:Issue with FSF statement... by Richard_at_work · 2014-09-27 00:41 · Score: 1, 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:Issue with FSF statement... by _merlin · 2014-09-27 00:48 · Score: 1, Insightful

You conflicted with their ideology and got a "-1 makes me uncomfortable" mod.
Re:Issue with FSF statement... by cyber-vandal · 2014-09-27 00:49 · Score: 1, 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:Issue with FSF statement... by javacowboy · 2014-09-27 00:57 · Score: 1

http://www.macosforge.org/

--
This space left intentionally blank.
Re:Issue with FSF statement... by cyber-vandal · 2014-09-27 01:00 · Score: 2

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:Issue with FSF statement... by Savage-Rabbit · 2014-09-27 01:04 · Score: 4, Informative

Everyone using Bash has the freedom to download, inspect, and modify the code -- unlike with Microsoft, Apple, or other proprietary software.
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 large portions of their OS X operating system including, it seems, the version of BASH 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.

--
Only to idiots, are orders laws.
-- Henning von Tresckow
Re:Issue with FSF statement... by lippydude · 2014-09-27 01:06 · Score: 5, Informative

@Richard_at_work: "I'd be interested to hear why the down modder thinks my points above are trolling"

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:Issue with FSF statement... by Anonymous Coward · 2014-09-27 01:08 · Score: 1

http://opensource.apple.com
Re: Issue with FSF statement... by samkass · 2014-09-27 01:26 · Score: 4, 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?

--
E pluribus unum
Re: Issue with FSF statement... by Savage-Rabbit · 2014-09-27 01:44 · Score: 1

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.

--
Only to idiots, are orders laws.
-- Henning von Tresckow
Re:Issue with FSF statement... by fnj · 2014-09-27 01:55 · Score: 1

He has no answer to that, and neither do the micro softies and apple corps who mod'ed him up.
Re:Issue with FSF statement... by fnj · 2014-09-27 02:03 · Score: 1

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:Issue with FSF statement... by fnj · 2014-09-27 02:14 · Score: 4, Informative

Show us some OS source code or shut the hell up, shill.
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.
Now YOU shut the fuck up, you clueless knuckle dragging cowardly fool,
Re:Issue with FSF statement... by Richard_at_work · 2014-09-27 02:20 · Score: 3, 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.
Re: Issue with FSF statement... by Anonymous Coward · 2014-09-27 02:35 · 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:Issue with FSF statement... by Savage-Rabbit · 2014-09-27 02:45 · Score: 1

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 shell? I'll let you figure out why you can't do that unless you work for Microsoft.

--
Only to idiots, are orders laws.
-- Henning von Tresckow
Re:Issue with FSF statement... by jedidiah · 2014-09-27 02:52 · Score: 1

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.

--
A Pirate and a Puritan look the same on a balance sheet.
Re:Issue with FSF statement... by Richard_at_work · 2014-09-27 02:57 · Score: 1

The difference between Savage Rabbits post and the FSFs statement is that the above post isn't a blanket one.
Re:Issue with FSF statement... by Richard_at_work · 2014-09-27 02:58 · Score: 1

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:Issue with FSF statement... by SuiteSisterMary · 2014-09-27 03:44 · Score: 1

I take issue more with the fact that it completely misses the point. "Everyone using Bash has the freedom to download, inspect, and modify the code....and yet this bug has been around for years."

--
Vintage computer games and RPG books available. Email me if you're interested.
Re:Issue with FSF statement... by ceoyoyo · 2014-09-27 03:46 · Score: 2

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... by ceoyoyo · 2014-09-27 03:50 · Score: 2

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:Issue with FSF statement... by gnasher719 · 2014-09-27 03:55 · Score: 3, 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:Issue with FSF statement... by tepples · 2014-09-27 04:06 · Score: 2

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. So I don't see how this is full source.
Re:Issue with FSF statement... by squiggleslash · 2014-09-27 04:07 · Score: 2

I suspect large numbers of people saw the bug, but didn't realize the implications and took no action knowing that the last thing you want to do with a programming language (which a shell like a bourne implementation implements) is change what constitutes valid code.
What does this mean? Unsure. It's always been bad practice to use system() or similar calls to start other apps. What this issue has revealed is not so much that bash has a bug in it, but that rather too many applications rely upon bash and shouldn't. Bash is always a vector, and writing code that calls it already means working a great deal on input validation exercises that risk failure.
The scary part is that a significant amount of the *ix community doesn't care - they call system() anyway, or blindly allow the shell environment to be modified, without asking themselves whether this is a good idea.

--
You are not alone. This is not normal. None of this is normal.
Re:Issue with FSF statement... by cyber-vandal · 2014-09-27 04:13 · Score: 1

Says the tantrum-throwing Apple fanboi.
Re:Issue with FSF statement... by smash · 2014-09-27 04:32 · Score: 2

So you are just writing off their contributions to webkit, CUPS, zeroconf, gcd, llvm, etc. Things that other operating systems and applications can and do benefit from?

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:Issue with FSF statement... by Savage-Rabbit · 2014-09-27 05:52 · Score: 2

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.

--
Only to idiots, are orders laws.
-- Henning von Tresckow
Re:Issue with FSF statement... by trust_jmh · 2014-09-27 06:42 · Score: 1

Everyone using Bash has the freedom to download, inspect, and modify the code -- unlike with Microsoft, Apple, or other proprietary software.
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.
You may think so but running on a closed OS you have no control over backdoors.
Debian specifically has "contrib" section to separate the true free code in "main" from those dependent on software not passing DFSG in "non-free".
Re: Issue with FSF statement... by rHBa · 2014-09-27 13:13 · Score: 1

Your average Linux desktop user has probably downloaded/installed a couple of bash updates in the last 48 hours, each one taking 5mins max.

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:Issue with FSF statement... by donaldm · 2014-09-27 17:26 · Score: 1

As per your link to bash , if you look at the "COPYING" part under the "bash-3.3" directory you will see the bash they are using is V3.2 and is under the GPLv2. This is not denigrate Apple's use of a GPLv2 product since it is open source, however it is an older version of bash.

If you look at the later releases of bash version 4.2 is actually under the GPLv3 license. The following is from my Fedora 20 distribution.
> rpm -q --queryformat="%{NAME}\t%{LICENSE}\n" bash-4.2.48-2.fc20.x86_64

bash GPLv3+

The above version of bash has been patched and is available as an update as per 2 days ago.

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.
That is assuming that the so called "major foreign government" has the people who can do a code review and they trust the release is the same one they did the code review on. For all but the most paranoid governments this type of thing really belongs in the "too hard basket" so most choose to believe that the closed source company is all "sweetness and light" and would never screw us over. :)

--
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
Re:Issue with FSF statement... by fnj · 2014-09-29 10:18 · Score: 1

At least the AC is now down mod'ed to -1. So mission accomplished. I think some people confuse well-deserved straightforward insults in connection with a factual refutation to a twit ... "flamebait", but plenty of others plainly do not.

Patches for 3.x bash versions? by javacowboy · 2014-09-27 00:48 · Score: 2

Aren't there shellshock patches available for the non-GPL 3'd versions of bash?

--
This space left intentionally blank.

Re:Patches for 3.x bash versions? by aNonnyMouseCowered · 2014-09-27 04:37 · Score: 1

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...
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 by evandyke · 2014-09-27 00:49 · Score: 5, Informative

Stackexchange has a link for anyone who wants to patch their own servers... I've been following it here: http://apple.stackexchange.com... I doubt we'll see a patch from apple until the community agrees that they have a working patch... sounds like they keep going down the rabbit hole right now; keep finding more issues. I upgraded my Lion Server with the current "official" patches, and also the "no function import" change. Better safe...

Bash a bad fit for osx by staalmannen · 2014-09-27 00:58 · Score: 2, Insightful

What Apple does (keeping an ancient non-gpl3 version of bash as primary shell) seems to be the worst possible solution. There are several powerful shells with liberal licences that would fit osx better: zsh (very powerful, globbing and spelling correction), mksh (light and fast but still full of features) or perhaps for the easy-to-use philosophy: fish. Osx already diverges significantly from other *nixes (case-insensitive, binary format, ...) so keeping bash for legacy support sounds strange - and if important they could just make it an optional install like in most BSDs...

Re:Bash a bad fit for osx by Anonymous Coward · 2014-09-27 01:14 · 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:Bash a bad fit for osx by Trepidity · 2014-09-27 02:50 · Score: 1

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.

--
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Re:Bash a bad fit for osx by smash · 2014-09-27 04:38 · Score: 1

I suspect the only reason apple currently uses bash as the default shell (it used to be plain sh from memory or csh) is that it makes it friendly to Linux users.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:Bash a bad fit for osx by brantondaveperson · 2014-09-27 13:14 · Score: 1

Case insensitive
Leaving aside the question case-sensitivity is sensible in a filesystem (does it make sense for anything other than performance?) - OSX does support case-sensitive filesystems.

binary format
What binary format? Every configuration file I've seen anywhere in OSX is XML. Not that I'm especially in love with XML, but binary it certainly isn't. What's more, reading these text config files into native dictionary, string and list structures is supported in the OS, which means that everyone uses them for everything.
Suggesting the a 20-year old bug in bash is Apple's fault because the bug isn't present in other shells doesn't make sense. Not that we have any reason to believe that zsh is any more secure anyway. I bet it's the same insane malloc, strcpy, free, etc etc infested C code that every other security-critical unix application is written in. It's only a matter of time until another bug of this magnitude, or maybe even worse, appears in that mess. Care to take a guess which piece of the puzzle will turn out to be broken next? No? Exactly. The whole thing's a crap shoot.
Re:Bash a bad fit for osx by jeremyp · 2014-09-29 00:28 · Score: 1

OS X comes with csh, bash, ksh and zsh. If you delete the link from sh to bash and replace it with a hard link to zsh, it probably secures your Mac.

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe

Re:Ars Technica speculates? by cryptizard · 2014-09-27 01:01 · Score: 3, 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.

Probably good to give another 48 hours anyway by raymorris · 2014-09-27 01:02 · Score: 4, 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:Probably good to give another 48 hours anyway by ls671 · 2014-09-27 08:02 · Score: 2

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 - Bash Attack'"
SecRule ARGS "^ {" \
"phase:2,deny,id:1003,t:urlDecode,t:urlDecodeUni,status:403,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule FILES_NAMES "^ {" \
"phase:2,deny,id:1004,t:urlDecode,t:urlDecodeUni,status:403,log,msg:'CVE-2014-6271 - Bash Attack'"
## End bash attack

--
Everything I write is lies, read between the lines.

Re:Ars Technica speculates? by gnasher719 · 2014-09-27 01:06 · Score: 2, 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.

Is it actually a bug at all? by anynameleft · 2014-09-27 01:24 · 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:Is it actually a bug at all? by Rockoon · 2014-09-27 02:17 · Score: 1

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.

--
"His name was James Damore."
Re:Is it actually a bug at all? by SuiteSisterMary · 2014-09-27 03:12 · Score: 1

Because nobody remembers the days when UNIX was just as 'keep security out of the way of the user' as Windows was. Nobody remembers the good old days of sendmail happily handing root access for the asking. 'wizard', 'debug', etc. Nobody remembers that UNIX is 'MULTICS with most of the security stripped out.' UNIX as in eunuchs as in a castrated version of MULTICS.

--
Vintage computer games and RPG books available. Email me if you're interested.
Re:Is it actually a bug at all? by __aaltlg1547 · 2014-09-27 03:33 · Score: 1

Yes, it is a bug. The shell shouldn't be evaluating expressions inside a quoted (or unterminated for that matter) string.
Re:Is it actually a bug at all? by __aaltlg1547 · 2014-09-27 03:39 · Score: 1

At least. I remember the original "Morris worm" which took advantage of default setups that were wildly insecure by any modern standard.
Re:Is it actually a bug at all? by AqD · 2014-09-27 05:36 · 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 their code at application-side plus ridiculous system setup could often nullify whatever protection you have in kernel/http-server, and magically enlarge every small bug into serious backdoor.
Re:Is it actually a bug at all? by david_bonn · 2014-09-27 06:34 · Score: 2

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 shell on your system, except possibly for testing or debuggery.
The cheapest, fastest, and most reliable components of any systems are the ones that aren't there. Oh, and the most secure as well.
Re:Is it actually a bug at all? by phantomfive · 2014-09-27 16:27 · Score: 1

'wizard', 'debug', etc.

What were those?

--
"First they came for the slanderers and i said nothing."
Re:Is it actually a bug at all? by SuiteSisterMary · 2014-09-28 01:49 · Score: 1

http://www.iss.net/security_ce...

--
Vintage computer games and RPG books available. Email me if you're interested.
Re:Is it actually a bug at all? by phantomfive · 2014-09-28 03:29 · Score: 1

Thanks

--
"First they came for the slanderers and i said nothing."
Re:Is it actually a bug at all? by phantomfive · 2014-09-28 03:31 · Score: 1

wow, that's a purposely built-in back door lol

--
"First they came for the slanderers and i said nothing."

Forget Apple engineers, use NetBSD's patch by Anonymous Coward · 2014-09-27 01:33 · 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...

You're welcome.

Re:Stackexchange has discussion on patching yourse by Zaiff+Urgulbunger · 2014-09-27 01:52 · Score: 1

Stackexchange has a link for anyone who wants to patch their own servers... I've been following it here: http://apple.stackexchange.com...

Does this work fine with Snow Leopard does anyone know?

MS patented "open", funky licenses by raymorris · 2014-09-27 02:06 · Score: 4, 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.

Use Macports by ugen · 2014-09-27 02:07 · Score: 3, Insightful

Macports updated their version of bash. Get macports here, if you don't already have them, and install bash: https://www.macports.org/
Make sure to move their bash into /bin and remove original Mac binary.

Re:Use Macports by _xeno_ · 2014-09-27 02:34 · Score: 1

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.

--
You are in a maze of twisty little relative jumps, all alike.

Comment removed by account_deleted · 2014-09-27 02:08 · Score: 1

Comment removed based on user account deletion

Re:Ars Technica speculates? by Anonymous Coward · 2014-09-27 02:55 · Score: 1

I expect they probably will in the end. It just takes time. They've already done it for gcc (clang), and gdb (lldb), I'm sure they'll get round to all of the other GPLv3 world eventually and BSD it instead.

Re: Stackexchange has discussion on patching yours by Anonymous Coward · 2014-09-27 03:05 · 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

I find this event a little suspicious. by Anonymous Coward · 2014-09-27 03:05 · Score: 1

This is not a very sophisticated flaw. The BSD's weren't effected, suggested that the flaw has been known in some circles for a VERY long time. Or at least the potential for a variety of related flaws in this area were known and considered, and make files were configured accordingly.

So why did it go Viral? Was the explosion of this flaw, a push or pull type event? And doesn't it drive home the point, that Linux distros should start patching more and forking less?

Re:Ars Technica speculates? by Richard_at_work · 2014-09-27 03:12 · Score: 2

So anyone not agreeing with your ideology is a sociopath? Don't you get the irony in that?

Re:Stackexchange has discussion on patching yourse by armanox · 2014-09-27 03:17 · Score: 1

I'm going to find out. I may test on Leopard as well (since I still have a quad G5)

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.

Have you ever used OS X? by Anonymous Coward · 2014-09-27 03:26 · Score: 1

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.

Re:Ars Technica speculates? by jo_ham · 2014-09-27 03:26 · Score: 4, 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:Ars Technica speculates? by jo_ham · 2014-09-27 03:31 · Score: 2

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 branded a sociopath?

Re:Ars Technica speculates? by ceoyoyo · 2014-09-27 03:58 · Score: 3, 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!

I've used every OS on the planet by Brannon · 2014-09-27 03:59 · Score: 1

OSX is my favorite, second to Linux. But honestly, it's isn't that close.

Not to praise Apple, but... by damn_registrars · 2014-09-27 04:01 · Score: 1

... really aren't Apple systems likely the *nix boxes that are least likely to be exploited by shellshock? I have a lot of Apple boxes at work (and know of lots of people who use them in other places as well) but I know of only a very short list of Apple boxes that have any public facing services. While a fair chunk of other *nix boxes are running web servers and other services that can provide avenues for exploiting shellshock, it doesn't seem particularly pressing for the Apple systems that are not.

--
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.

Re:Not to praise Apple, but... by smash · 2014-09-27 04:44 · Score: 1

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 is exploitable.
But hey, let's make out that OS X is worse off than Linux in this case.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:Not to praise Apple, but... by damn_registrars · 2014-09-27 05:14 · Score: 1

Far more vulnerable is Linux which runs dhcpd on any machine with a non-static IP, through which bash is exploitable.

Although not every Linux distro installs bash as a shell by default. AFAIK OS X always installs bash unless the user goes back an uninstalls it.

In other words I would say the two are roughly equally vulnerable. You can't compromise bash if it isn't installed (on various other *nixes) nor can you compromise bash if you can't get to it because no public services are installed that can call upon it (OS X).

--
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Re:Not to praise Apple, but... by brantondaveperson · 2014-09-27 20:19 · Score: 1

Equally vulnerable? That's a whole bunch of thinking you've got going on there.
Default OSX install. Not vulnerable.
Default Linux install (assuming dhcpd is the default). Boom. Owned.
Not super-equal, I'd say.
Actually making OSX vulnerable to this bug would require some php or whatever hooked up to the web server and invoking a shell. For some-one that knows what they're doing, this is easy because OSX does ship with apache after all. But really, how would this be Apple's fault?
Re:Not to praise Apple, but... by damn_registrars · 2014-09-28 01:17 · Score: 1

Default Linux install (assuming dhcpd is the default). Boom. Owned.
You neglected your second - and more profound - assumption.

You have to have bash installed as well in order to be vulnerable. Not every linux install installs bash by default.

In other words, you are comparing an OS that has a vulnerable shell by default (OS X) with an OS that has a vulnerable dhcp by default (Linux) and making an assumption that the Linux install has the vulnerable shell as well.

--
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Re:Not to praise Apple, but... by OneAhead · 2014-09-28 05:07 · Score: 1

It pains me to defend the Apple fanboi, but what you say is not entirely true. The DHCP client in question explicitly calls "/bin/bash"; bash is a dependency for it. Of course, there do presumably exist Linux distros that use a different DHCP client, but in my understanding, the vulnerable one is quite widespread. The only saving grace (for a short time) is that remotely exploiting the DHCP client flaw is substantially more complex than remotely exploiting the web server flaw, and that the major distros already released full patches by yesterday morning.
Re:Not to praise Apple, but... by brantondaveperson · 2014-09-28 15:30 · Score: 1

I find myself defending Apple alot on this site, because most of the criticism of them is just simply false. Their design is not 'flashy' (it's actually rather plain), their security record is excellent (as far as I know - I've certainly never had any issues of any sort), their OS is an actual Unix on which I can get lots of actual work done. etc etc etc.
However, A fanboi I am not. Their refusal to allow me to put native code on my own iPod touch without paying money to them is indefensible. I understand why, it completely defeats piracy and maintains a high quality of apps. But man it's a pain in the ass and the very opposite of why I got into computers in the first place. The 32G iPad is $150 more expensive than the 16G model! WTF?! OSX is not as stable as Windows 7, their filesharing protocol keeps crapping out, etc etc.
Anyway - thanks for your defence. Around here voices of actual reason are a little rare.... :)
Re:Not to praise Apple, but... by OneAhead · 2014-09-28 20:04 · Score: 1

OSX is not as stable as Windows 7
That one's new to me, actually, though I haven't used either for appreciable periods of time so I cannot really know.

Apple v. Apple by tepples · 2014-09-27 04:01 · Score: 1

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:Stackexchange has discussion on patching yourse by armanox · 2014-09-27 04:25 · Score: 2

Confirmed that it works on Snow Leopard.

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.

Re:Sounds like Apple. by smash · 2014-09-27 04:27 · Score: 1

Apple deprecated Java entirely and suggested that you obtain it from Oracle, but thanks for playing.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.

Re:Ars Technica speculates? by smash · 2014-09-27 04:37 · Score: 2

The amount of GPL code in OS X userland is exceedingly minimal. Most of it is from FreeBSD.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.

Re:FreeBSD has as well STILL not patched. by smash · 2014-09-27 04:40 · Score: 1

bash is not part of FreeBSD.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.

Re: Stackexchange has discussion on patching yours by Zaiff+Urgulbunger · 2014-09-27 04:51 · Score: 1

Brilliant! Thank you!!

The whole function exporting mechanism is a bug by ebcdic · 2014-09-27 04:54 · Score: 1

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:The whole function exporting mechanism is a bug by spitzak · 2014-09-27 18:28 · Score: 1

That is an excellent idea. Somebody should mod this up!
The way bash is doing this is a ridculous hack and it is not suprising it is also a huge security hole.
You can set an envoronment variable in bash to a value that will cause recursively-called bash to think it is a function, white it is not a function in the bash that defined it. That is just stupid.
Re:The whole function exporting mechanism is a bug by OneAhead · 2014-09-28 05:14 · Score: 1

Yes, that was Florian Weimer's suggestion as discussed in the arstechnica article (which is probably where you got the idea), and is exactly what they did in the last round of patches.
Old behavior:
x() { echo foo; }; export -f x; env | grep foo x=() { echo foo

New behavior:
$ x() { echo foo; }; export -f x; env | grep foo BASH_FUNC_x()=() { echo foo

Re:Ars Technica speculates? by kthreadd · 2014-09-27 05:46 · 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...
https://ftp.gnu.org/gnu/bash/b...

Re:Ars Technica speculates? by kthreadd · 2014-09-27 05:50 · Score: 1

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:FreeBSD has as well STILL not patched. by kthreadd · 2014-09-27 05:56 · Score: 1

But it is part of the ports collection, which is managed by the FreeBSD project and that a lot of FreeBSD users use.

Re:Yo, bash upstream by kthreadd · 2014-09-27 05:57 · Score: 1

There are users using it, and it is documented.

Paging Dr. House by ColdWetDog · 2014-09-27 07:18 · Score: 2

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.

--
Faster! Faster! Faster would be better!

Re: FreeBSD has as well STILL not patched. by aanantha · 2014-09-27 07:54 · Score: 1

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 attempt at fixing this.

FreeBSD isn't even vulnerable to begin with. /bin/sh is Almquist shell.

Homebrew anyone? by ALeader71 · 2014-09-27 08:19 · Score: 1

Is it me, or am I the only one who used Homebrew to replace the installed version of bash?

--
Only the dead have seen the end of War. - Plato

It's UNIX, and this 1U disagrees with you by raymorris · 2014-09-27 15:40 · Score: 1

OS X is certified UNIX. You know, the network operating system that was serving clients before Xerox invented the desktop.
I have a 1U OS X. server here that says you're clueless.

Re:Sounds like Apple. by phantomfive · 2014-09-27 16:52 · Score: 1

Once you've had Mac [apple.com], you can't go back!

Until you realize Apple has no commitment to backwards compatibility, and the software you bought three years ago is useless. Then you become bitter and depraved.

--
"First they came for the slanderers and i said nothing."

Re:Ars Technica speculates? by kthreadd · 2014-09-27 20:27 · Score: 1

By convention patches are released under the same license as the version it applies to. I'm sure the GNU Bash maintainer is willing to clarify this to Apple if asked.

Shellshock a result of inappropriate use of bash by r7 · 2014-09-28 03:37 · Score: 1

Shellshock does a good job of illustrating a fundamental security flaw in
bash but also in Redhat. Redhat, Fedora and CentOS are the most at risk
OSs because Redhat decided to make bash the default shell. This was a
deeply flawed system design decision driven by NIH (not invented here
syndrome). The problem is that bash was written and is maintained by
Redhat. As a result scripts that should have been written in the Bourne
shell are instead using bash. Even scripts that use Bourne (/bin/sh) are
executing bash on Redhat systems as sh is symlinked from bash. This is
not the case on Debian-based Linux (Ubuntu et al) as they don't symlink
bash to sh or specify bash as the default shell script interpreter.
Neither is it the case on the BSDs which don't even ship with bash.

So why then is bash an inappropriate choice for shell scripting? Bash is
designed to be an interactive shell. As a result it a much larger
program and has a correspondingly larger codebase than Bourne, most of
which is dedicated to auto-completion and other interactive features.
All else being equal (and it is in this case) more code correlates with
less security. Bash is also not POSIX-compliant. As a result it is not
cross-platform compatible nor are its features or design subject to
substantial design review. This and other reasons (like security) are
why all Unix and Linux distributions other than Redhat specify POSIX
Bourne as the default shell scripting language.

Redhat aside many third party shell scripts are written in bash that use
no bash features i.e., they would run with little or no modifications
under sh. So why are these scripts written in bash? The primarily
reasons are A) script authors don't understand or value cross-platform
compatibility and B) don't know the differences between bash and sh
(commonly due to familiarity with bash as an interactive shell). A third
but equally important factor is the lack of formal Linux or Unix
training.

Just as shell scripts should not be written in csh (or tcsh) they should
also not use bash (or ksh). Shell script authors should A) keep it
simple, B) be aware of cross-platform differences, C) value
POSIX-compliance and D) value security. With these best practices bugs
like shellshock won't have such an impact.

Arstechnica = fail by OneAhead · 2014-09-28 04:31 · Score: 1

The Arstechnica journalist Sean Gallagher really dropped the ball on this one:
- His information was behind even when it was published. On the 25th of September around 22:00 EST (depending on the version you're running), Debian issued a patch that fixes the new vulnerabilitys CVE-2014-7186 and CVE-2014-7187 AND implements the Florian Weimer suggestion, strongly mitigating the exploitability of any future parser bugs. Red Had and Ubuntu took their sweet time validating this patch suite, but eventually followed suit the evening of the 26th and the morning of the 27th, respectively.
- The Norihiro Tanaka "bug" is documented and intended behavior, which Sean Gallagher could have known simply by clicking next in thread! Specifically, it's how bash passes shell functions to a subshell. Unlike shellshock, it could only be exploited remotely when allowing a remote attacker to set variables with arbitrary names, which is not the case for any widespread software package. If it was, you'd be lost regardless of which shell you're using and it would have been exploited ages ago. Even the Florian Weimer improvement doesn't change this.

Re:Arstechnica = fail by harryjohnston · 2014-09-28 10:21 · Score: 1

It could also be exploited remotely if the function parsing code has any bugs in it. Several have already been discovered, including one that is probably remotely exploitable.
http://lcamtuf.blogspot.co.nz/...
Re:Arstechnica = fail by OneAhead · 2014-09-28 19:58 · Score: 1

You might want to read my post again. Slowly. Note that in my last paragraph, I was not talking about CVE-2014-6271, but about the other thing Norihiro Tanaka tried. Also note the presence of the word "unlike" in my post. Either you missed that, or you misunderstood the information in your link. If so, to clarify: the old by-design behavior for passing a function to a subshell was by itself not remotely exploitable; it merely forced the shell to parse each and every env variable, making any bugs in the parser (we're counting 6 so far if I'm still keeping track) remotely exploitable. What Florian Weiner did is essentially limit the parsing of env variables to the ones that start with "BASH_FUNC_", which ordinarily cannot be set remotely (unless the daemon or client is criminally insecure). This is more a "defense in depth" style security enhancement than an actual bug fix, and it does have the potential of breaking bash scripts that are too tricky for their own good. It's also a must-have, long overdue, and has the beneficial side effect of eliminating potential namespace collisions between shell functions and other variables, so the "too tricky for their own good" script authors will have to suck it up.
Re:Arstechnica = fail by harryjohnston · 2014-09-29 07:24 · Score: 1

You're quite right, I hadn't read the article you were referring to - assumed it was more of the same, to be honest - and so was reading your post out of context. Sorry about that and thanks for the clarification.
As far as I know, though, bash itself (the upstream version) hasn't accepted the comprehensive patch yet? I think that's what the writer meant, not that none of the individual distributions have applied it.

Re:Shellshock a result of inappropriate use of bas by OneAhead · 2014-09-28 04:57 · Score: 1

You have a lot of good and true points, but there are couple of huge mistakes in your post that I cannot let stand uncorrected.

AFAIK, the original Bourne shell hasn't been maintained since 1989 or so; if you were to distribute it today as /bin/sh , your distro would doubdlessly be plagued by the most embarrasing buffer overflow and other vulnerabilities. What Debian and its derivatives do is link /bin/sh to dash , the Debian Almquist Shell, which is a modern and well-maintained project aimed at providing a lightweight shell that throws out all interactive features yet has a rich set of non-interactive scripting features that far surpasses the original Bourne shell - not as rich as bash, but good enough for present-day shell scripting. I remember when they took the jump (which required months of preparation consisting of purging bashisms from common shell scripts), boot times were suddenly slashed in half because repeatedly initializing dash processes is so much lighter on the system than doing the same with bash. And as you said, as a side effect, security also benefits.

Redhat aside many third party shell scripts are written in bash that use no bash features

This is factually incorrect; when was the last time you installed something that didn't come out of a Debian repository? Red Hat is incredibly popular in corporate environments, and almost all 3rd party "#!/bin/sh" scripts are actually shock full of bashisms because their customers ask them to target Red Hat and their programmers are Red Hat inbreds who wouldn't know a bashism if it hit them in the head. And remember that a lot of FOSS development is being done within corporations... The pervasive bashisms are why it took Debian so much effort to switch and why Red Hat never did.

Deja Vu by lucien86 · 2014-09-28 07:42 · Score: 1

This is almost exactly the vulnerability I identified in Linux and other Unixes in about 2002. I was looking for a totally secure type of OS for running a machine that needed very high security. It was only really a guess or a hunch but the shell looked like one of the biggest weak points, another for my app was fork - the biggest weakness of all though was the shear complexity of the whole unix system.
My design was abandoned because a suitable OS couldn't be found, and is now being reimagined as running raw on FPGA hardware - with a thin bespoke OS layer.

--
Below the speed of light Special Relativity is one of the most accurate theories in physics - above the speed of light..

Backporting not an issue by harryjohnston · 2014-09-28 10:23 · Score: 1

Backporting the patch(s), or fixing it from first principles for that matter, is unlikely to be an issue. The problem just isn't that complicated.

The delay is more likely due to Apple's more rigorous testing regime.

Slashdot Mirror

Apple Yet To Push Patch For "Shellshock" Bug

150 of 208 comments (clear)