The attack surface for shellshock is insanely large, and it's crazy to leave bash unpatched even if one or two currently-known vectors happen to not currently be known to be exploitable. People will be finding ways to tickle it for years to come.
That's not applicable here. Even NetworkManager on Linux isn't susceptible to this hack. dhclient and dnsmasq can apparently be shocked on unpatched Linux, though.
Um... the effort I had to take to patch my linux boxes was: Do nothing. (security fixes had been released and installed before I learned of the bug).
The effort I'll have to take to patch my Mac is:
* Download a new bash.
* recompile it
* install it by hand.
(and this is assuming I already have xcode/developer tools installed).
Not quite the same level of effort.
Is the article wildy off topic? Not really - its an article about yet another instance of Apple ignoring security issues, why wouldn't a previous example be relevant?
Is your position that a software vulnerability the only type of security issue? Is your position that ignoring software vulnerabilities is fundamentally a different thing than ignoring other types of security issue? I'm confused by why you are asking.
OS X: Install xcode, install xcodetools (CLI), download bash source code from a mostly-undocumented URL (need to search through apple support forums), download and manually apply patch from GNU. Build bash, manually copy build output into /bin.
That doesn't change the version of bash pointed at by /bin/sh which is a hardlink to the OSX supplied bash. Even if you previously relinked /bin/sh to a homebrew bash, it won't change versions by upgrading the installed bash.
It's definitely homebrew, Apple hasn't patched their binaries. Don't let this give you to a false sense of security. Many scripts could still be hardcoded to use your vulnerable /bin/bash binary, and many more won't load the PATH variable from your ~/.bash_profile. The only way to fix the problem is to patch /bin/bash and /bin/sh, updating homebrew is not nearly enough.
Homebrew has patched Bash for all 3 recently announced vulnerabilities, yes. The vulnerable bash will still be lurking on your system though, in /bin/bash and /bin/sh.
> While it should actually be a reasonable assumption, this is likely inaccurate both concerning public servers
Funny, I have personally worked at a company which ran their frontend on Mac Mini's. They weren't using CGI, but at least part of the assumption that people don't run Apple web servers is false.
Also, Mac supports running an Apache instance configured to run CGI scripts out of the box, correct? I haven't personally used it.
> Also, Mac supports running an Apache instance configured to run CGI scripts out of the box, correct? I haven't personally used it.
OSX does have Apache configured by default to run CGIs out of /Library/WebServer/CGI-Executables, but there is nothing in that folder by default, and you have to manually start Apache yourself, either with apachectl or via the System Preferences GUI.
Apple really got off super easy on the iCloud thing. As the article alludes to, they knew for months before the break-in, heck a lot of people on HK knew for months before the break-in (there was an article about it months ago) and yet they did nothing. Then when someone utilised that well publicized issue to break into accounts they pretended like they couldn't have seen this coming and it was a "targeted break-in" whatever the heck that means.
If it was any other company they would have got shit all over. Apple just has a very poor security culture internally, they're like Microsoft pre-Windows XP SP2. Microsoft made a huge cultural shift, it is about time Apple do the same.
>> "Apple really got off super easy on the iCloud thing"
I think you're confusing two separate issues here. There was a flaw in iCloud but the photo hacking incident which some seem to be alluding to ("break-in") was, from what I've read, done through phasing attacks, password/secret question guessing, and general social engineering rather than through a hole in iCloud. The two things were unrelated.
You realise the flaw in iCloud was that it allowed unlimited password guesses[0], right? So in effect what you just claimed is that the attackers used the known flaw in iCloud but that the two incidents are "unrelated."
If attackers used dictionary attacks or brute forcing against iCloud's APIs then that is the very flaw of which we speak. Everything I've read is that they did do exactly that, therefore it is easy to claim that the flaw and the theft are related.
There is a handy script to get the Bash tarball from opensource.apple.com, apply patches 52, 53, and 54 from ftp.gnu.org, build it, and then prompt to replace /bin/bash and /bin/sh. Xcode required.
For anyone wanting to patch their Mac (especially any older Macs, right back to 10.4 PPC) to the latest 4.3.27 bash without compiling themselves, TenFourFox posted a binary a few hours ago & some simple Terminal instructions:
TenFourFox are the people behind Firefox for old PPC Macs. The binary they posted today includes a patch for CVE-2014-6277, which bash 4.3.26 didn't have.
Want to get mad at a company? How about Netgear, which as far as I can tell has provided no official statement, warning, or patch for their consumer routers and APs.
Or how about LG? I have an LG Linux-based smart TV and I can't find one thing they've said about Shellshock. (In fact, I have not received a software or firmware update to that TV for well over a year at all.)
Or how about Synology, who said almost the exact same thing Apple did. Where are the posts suggesting we all stop putting our data into Synology NAS?
> A thorough investigation by Synology shows the majority of Synology NAS servers are not concerned. The design of Synology NAS operating system, DiskStation Manager (DSM), is safe by default. The bash command shell built-in in DSM is reserved for system service use (HA Manager) only and not available to public users. For preventive purpose, Synology is working on the patches addressing this bash vulnerability and to provide them as soon as possible.
“The vast majority of OS X users are not at risk to recently reported bash vulnerabilities… With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.” -Apple
Apple says they are working on a fix. Given that other vendors like RedHat had to issue multiple patches before they finally squashed the bug, I think it is far too early to claim that Apple isn't fixing this in a timely manner.
Sorry, but you have no idea what you're talking about.
The first patch released took the exploit from "Know way to easily remote execute code" to "Parser error that might be exploitable but we're not sure how to actually use it". If the Linux/BSD world had stopped there, they still would have done a far better job than Apple has. But they didn't stop there. They released a second patch. And now everyone is secure.
Meanwhile, the rest of the world and I are watching through our Apache logs as attackers are knocking at our front door with this exploit. If you have a OS X server and you didn't patch it already, you may already be exploited.
48 comments
[ 3.2 ms ] story [ 102 ms ] threadApple hard links /bin/sh to bash.
They could switch /bin/sh to an Almquist shell like dash to mitigate Shellshock.
https://www.trustedsec.com/september-2014/shellshock-dhcp-rc...
The DHCP vector was demonstrated to be an issue with various Linux distributions.
2) People do use Macs as servers. It's unwise, clearly, but it is done. https://www.apple.com/osx/server/
3) OSX server is setup for CGI by default, all you have to do is throw some scripts in the right directory.
So getting back to shellshock on OSX...
Is there a patch available?
yes.
Does it download via a GUI?
no.
Is it about the same level of effort to patch a OSX box as a GNU/Linux box?
yes.
Does the post go wildly offtopic to address issues (iCloud) that are likely wetware hacks? yes.
Does it recommend carte blanche to not use apple products because their OS is fully patched? yes.
The effort I'll have to take to patch my Mac is:
* Download a new bash.
* recompile it
* install it by hand.
(and this is assuming I already have xcode/developer tools installed).
Not quite the same level of effort.
Is the article wildy off topic? Not really - its an article about yet another instance of Apple ignoring security issues, why wouldn't a previous example be relevant?
Linux: apt-get install bash
OS X: Install xcode, install xcodetools (CLI), download bash source code from a mostly-undocumented URL (need to search through apple support forums), download and manually apply patch from GNU. Build bash, manually copy build output into /bin.
Yeah, totally the same level of effort.
Maybe it's homebrew patching it...
What does
give you?$ env X="() { :;} ; echo busted" /bin/bash -c "echo wow"
that'll pop out of usr, so you'll fail.
Funny, I have personally worked at a company which ran their frontend on Mac Mini's. They weren't using CGI, but at least part of the assumption that people don't run Apple web servers is false.
Also, Mac supports running an Apache instance configured to run CGI scripts out of the box, correct? I haven't personally used it.
OSX does have Apache configured by default to run CGIs out of /Library/WebServer/CGI-Executables, but there is nothing in that folder by default, and you have to manually start Apache yourself, either with apachectl or via the System Preferences GUI.
If it was any other company they would have got shit all over. Apple just has a very poor security culture internally, they're like Microsoft pre-Windows XP SP2. Microsoft made a huge cultural shift, it is about time Apple do the same.
I think you're confusing two separate issues here. There was a flaw in iCloud but the photo hacking incident which some seem to be alluding to ("break-in") was, from what I've read, done through phasing attacks, password/secret question guessing, and general social engineering rather than through a hole in iCloud. The two things were unrelated.
If attackers used dictionary attacks or brute forcing against iCloud's APIs then that is the very flaw of which we speak. Everything I've read is that they did do exactly that, therefore it is easy to claim that the flaw and the theft are related.
[0]http://www.macrumors.com/2014/09/25/apple-icloud-flaw-six-mo...
https://github.com/tjluoma/bash-fix
(yes, you have zsh on OSX by default)
http://tenfourfox.blogspot.com/2014/09/bashing-bash-one-more...
TenFourFox are the people behind Firefox for old PPC Macs. The binary they posted today includes a patch for CVE-2014-6277, which bash 4.3.26 didn't have.
> "we are working to quickly provide a software update."
http://www.huffingtonpost.com/2014/09/26/shellshock-bug_n_58...
Want to get mad at a company? How about Netgear, which as far as I can tell has provided no official statement, warning, or patch for their consumer routers and APs.
Or how about LG? I have an LG Linux-based smart TV and I can't find one thing they've said about Shellshock. (In fact, I have not received a software or firmware update to that TV for well over a year at all.)
Or how about Synology, who said almost the exact same thing Apple did. Where are the posts suggesting we all stop putting our data into Synology NAS?
> A thorough investigation by Synology shows the majority of Synology NAS servers are not concerned. The design of Synology NAS operating system, DiskStation Manager (DSM), is safe by default. The bash command shell built-in in DSM is reserved for system service use (HA Manager) only and not available to public users. For preventive purpose, Synology is working on the patches addressing this bash vulnerability and to provide them as soon as possible.
Many routers will similarly be using ash/BusyBox, though I agree they should issue a statement.
Apple says they are working on a fix. Given that other vendors like RedHat had to issue multiple patches before they finally squashed the bug, I think it is far too early to claim that Apple isn't fixing this in a timely manner.
The first patch released took the exploit from "Know way to easily remote execute code" to "Parser error that might be exploitable but we're not sure how to actually use it". If the Linux/BSD world had stopped there, they still would have done a far better job than Apple has. But they didn't stop there. They released a second patch. And now everyone is secure.
Meanwhile, the rest of the world and I are watching through our Apache logs as attackers are knocking at our front door with this exploit. If you have a OS X server and you didn't patch it already, you may already be exploited.