Best practices for patching the bash vulnerability

[elliotjordan]

Has anybody created a good workflow for this yet? I'll be working on deploying a patch tomorrow, and would love to hear from those on the bleeding edge.

[Lotusshaney]

I have created a compiled version of bash 3.2.52 for 10.6, 10.7, 10.8 and 10.9 and made an installer that does the hard work for you. You can deploy if via Casper, ARD or double click on the installer.

Please fill free to download it from my blog

http://blog.designed79.co.uk/?p=2000

[CasperSally]

Here is some more info on compiling

http://alblue.bandlem.com/2014/09/bash-remote-vulnerability.html

It sure would be nice when Apple releases a fix if it doesn't require you to be latest rev of OS. We are 10.9.4 (and don't have staff/resources to push 10.9.5 to all of our computers), and I'm pretty confident Apple's fix won't work for us.

For things like this, Apple should release a small update that can be pushed to every customer. We'll see.

[NowAllTheTime]

I've sent in a request to our TAM at Apple to see if we can get any general timeline of an update and what OS versions will receive the patch. I'm hoping we see something for at least as far back as 10.7. I'm not optimistic I'll get any additional info before the rest of the public does, but if I get any specifics on Apple's strategy for patching this vulnerability I'll be sure to share it here.

[tron_jones]

http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-...

Here's another way.

[CasperSally]

My enterprise ticket response was "Thank you for raising your concern regarding the publication of CVE-2014-6271. For the protection of our customers, Apple does not disclose, discuss or confirm security issues until a full investigation has occurred and any necessary patches or releases are available. I would recommend to monitor the security updates from our Product Security team as outlined on the following page.
https://www.apple.com/support/security/
"

[Lotusshaney]

tron_jones that is the process used to make the binaries in my installer

[tron_jones]

@Lotusshaney][/url

Tested on two machines with both methods. Your .pkg worked great. Thanks for packaging it up. For anybody that doesn't know, you can check your version of bash by opening up a terminal and running

bash --version

[NowAllTheTime]

@CasperSally Welp, that's disappointing. I won't hold my breath for anything more than that on my end either.

[dpertschi]

@Lotusshaney

Ditto, your package works for me, thanks for wrapping that up so fast. I love this place!

It's always good fun to have a solution before security dept. comes asking about something.

[CasperSally]

@dpertschi it would be even more good fun if Apple were as fast and flexible.

[nessts]

Seems to me, if you are truly worried about a security vulnerability, you ought not to be taking bash compiled by anybody else outside of Apple. Not questioning @Lotusshaney and his good heartedness, but what a great way to get your own vulnerability into the wild...
Being that this has existed for quite some time, and there are no known exploits, one might think we could wait a day or two for Apple. maybe make sure ssh is locked down to our admin users, notify our users that being stupid and going to questionable websites might not be the best plan for now. Only install software that is signed from trusted vendors (oh wait, anybody installing any software from a package is at the mercy of the packager with or without this vulnerability.)
I think unless one of my customers demands a fix today, I will be waiting, especially since there is speculation that current fix is not complete too, but only speculation.

[donmontalvo]

@nessts I agree, if you're running a business, might be better to wait for Apple. Now that word is spreading, shouldn't be long before a Security Update is released. I hope. Hacking business systems is unnecessary overhead, now and later if it gets in the way of Apple's own fix.

[Lotusshaney]

Agreed, but my company is a huge global education supplier and take security very seriously so I have to have a patch ready. Apple cant or wont give a time line for it

[mm2270]

Have to agree with some of the later posts here. I'm not questioning the legitimacy of LotussHaney's installer. I'm sure its fine and works fine, but at the org I'm at they would never approve of installing something not from the vendor directly, at least in relation to patching a vuln. If we complied it ourselves in house, perhaps security would be OK with that, but I'm not even sure about it in that case.
We're submitting a ticket with our enterprise AppleCare support and waiting to hear from them. I'm sure Apple will release a patch soon enough. My only remaining concern will be that we won't likely see a patch for anything under 10.9, so we may need to take some action for our clients still on 10.8 and 10.7, assuming this affects them and I think it does.

On a side note here, I'm not the least bit surprised this is happening. Apple has been routinely ridiculed by the 'nix admins on sites like SuperUser and StackOverflow for shipping an out of date version of bash with OS X. I really wish they'd stay on top of that a little better. I know there are some rare cases where having an older version of an open source product has actually paid off for Apple, but more often than not it can lead to these kinds of security issues.

[tron_jones]

Yeah, I have the luxury of waiting for Apple here where I am. I used the stack exchange method and compiled one on my own if needed.

http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

[GaToRAiD]

Guys, I found a great article on how to patch the vulnerability. I've tested and this fix's it completely until Apple can come out with a patch.
http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7

[#18]

There are in-the-wild exploits happening, so if you have publicly-available machines or anything critical, you might at least want to consider patching or otherwise hardening:

https://gist.github.com/anonymous/929d622f3b36b00c0be1

[Chris_Hafner]

Yep... I'm waiting on Apple as well. Not to say that we're not at the top of our game on the educational side of things. I just can't justify the 'fix' when Apple (God help me for saying this) must be prepping a fix right around the corner. Hopefully, I'll still be able to make phone calls after ;-)

[Lotusshaney]

Totally agree about the privacy concerns. I also would be doubtful of it to be honest. It just that I know most people won't know how to compile from source. Also I have a lot of older 10.6 and 10.7 clients and I know Apple won't patch them but my build will and that might help others.

[donmontalvo]

@Chris_Hafner I saw what you did there. ;)

Hopefully, I'll still be able to make phone calls after ;-)

[mm2270]

Hehe. I didn't actually get that at first (slow day for me I guess) but I do now. Good one! :)

As for this issue, thanks for the heads up about the exploits in the wild. Its good information to have, even we ultimately decide to wait on Apple for an official fix. If it looks like it will take too long to get that fix, then I guess we'll need to use one of the above links to compile our own and distribute it. Hopefully Apple won't be dumb@sses and allow it to get to that point though.

[elliotjordan]

Apparently there are two different vulnerabilities at the moment. The original one, @GaToRAiD and @tron_jones pointed out). The new one, CVE-2014-7169, has not yet been patched as far as I have seen.

I'm waiting to deploy anything until both are confirmed to be patched.

[Xopher]

Hi,
Anyone have a Extension Attribute for reporting the bash version?

[GaToRAiD]

@elliotjordan The second one CVE-2014-7169 is fixed by the instructions in the link. The only thing that is not fixed is it still creates a file in the location that it is run in. The file is blank and has no contents in it.

[tron_jones]

@Lindsey

#!/bin/bash

echo "<result>$(bash --version | awk '{print $4}' |  sed -e 's|Free||g')</result>"

[jarradyuhas]

#!/bin/bash

#bash 3.2.52 replacment
#v1.0 Daniel Shane 22/09/14

swv=`sw_vers -productVersion | cut -d . -f 1,2 | sed 's/.//g'`
install_dir=`dirname $0`

if [ $swv -lt 106 ]; then
    logger "bash_replacment : Unsupported OS Version Detected"
    exit 1
fi

if [ $swv -gt 109 ]; then
    logger "bash_replacment : Unsupported OS Version Detected"
    exit 1
fi

if [ $swv -ge 108 ]; then
    logger "bash_replacment : Mac OS X 10.8 or Higher Detected"
    mv "$3"/bin/bash "$3"/bin/bash.apple
    mv "$3"/bin/sh "$3"/bin/sh.apple
    cp "$install_dir"/10.9/bash "$3"/bin/
    cp "$install_dir"/10.9/sh "$3"/bin/
    chmod a-x "$3"/bin/bash.apple
    chmod a-x "$3"/bin/sh.apple
    chown root:staff "$3"/bin/bash
    chmod 555 "$3"/bin/bash
    chown root:staff "$3"/bin/sh
    chmod 555 "$3"/bin/sh 
fi

if [ $swv -lt 108 ]; then
    logger "bash_replacment : Mac OS X 10.7 or Lower Detected"
    mv "$3"/bin/bash "$3"/bin/bash.apple
    mv "$3"/bin/sh "$3"/bin/sh.apple
    cp "$install_dir"/10.7/bash "$3"/bin/
    cp "$install_dir"/10.7/sh "$3"/bin/
    chmod a-x "$3"/bin/bash.apple
    chmod a-x "$3"/bin/sh.apple
    chown root:staff "$3"/bin/bash
    chmod 555 "$3"/bin/bash
    chown root:staff "$3"/bin/sh
    chmod 555 "$3"/bin/sh
fi

exit 0

I just wanted to post the package contents of the update that was published above. If anyone sees anything glaring regarding this, please feel free to shout.

[Xopher]

@ tron_jones

Thank you, much appreciated!

[iJake]

I crafted my extension attribute to make the version number an integer so it could be easily used with smart groups if anyone wants to use it.

#!/bin/sh

bashVersion=`bash --version | head -1 | awk '{print $4}' | head -c 6 | tr -d '.'`

echo "<result>$bashVersion</result>"

[chris_kemp]

Can someone elucidate for me what exactly the client-side risks are here? From my reading, the biggest worry seems to revolve around malformed http requests causing code execution on the server side. The ssh and DHCP request possibilities I get - but wouldn't these, in general, involve another breach (such as a rogue DHCP server) to be a major concern?

Not to say this isn't a concern, of course - but if the larger, more immediate concern is in fact with server-side services, then I don't see the need to run out and patch BASH on all our workstations today. Am I missing something?

[ImAMacGuy]

@chris.kemp thank you - our security dept is running around with their hair on fire, but they don't know exactly what it's about either, and unfortunately it's a bit over my head to understand (every time I tried I went cross eye, started drooling, and got a bad twitch - not cool) so I haven't been very effective at mitigating their fears. If someone can chime in and explain it that would be great!

To me it's just hype because "...nothing ever happens to apple devices".

[GaToRAiD]

@jwojda here is some more information that might help you and your security department.
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

@chris.kemp is certainly correct with his assumption.

My security department only required that we patch the externally facing webserver of JSS. Once they were able to run a nexpos scan on the system externally and see that it was no longer vulnerable, they were fine with just waiting for apple to patch all of our client systems. The main issue at hand is hitting and webserver and injecting the code via CGI.

[nessts]

To put it in the plainest hopefully close to English I can, as I understand it. If you have a web server running mod_cgi, or other services that can read remote variables from a bash configuration file, and you manage to be running this in a 20+ year old way that makes this execution possible, and your cgi script happens to be in bash instead of perl, then a very smart malicious individual could get your server to execute an operation that could then create files, worms etc on your server. The big problem here is that if this happens and they create a worm on a system that had http running as root then the system is a goner the attacker would then own it, could have it create new accounts, turn on new services etc.
The avenues that I see that a client could get affected is if a user downloads some script and runs it not knowing what the script does then it could possibly gain root access if the user was an admin and typed their sudo password or something like that, and really this exists as a problem with or without Shellshock.
Physical access to the client, and editing their bashrc file and turning on something malicious like a key logger. And if the bad guys have physical access to a client machine i think Shellshock is the least of your worries, and really this exists as a problem with or without Shellshock.
Installing a package with malicious code, which is a problem with or without Shellshock, because if you install a package from a creep that wants to control your machine, if you authorize that with an admin password all bets are off on that computer.

Again there are other devices and avenues with other openings I am sure, and I am not trying to discount the seriousness of the vulnerability and the possible far reaching consequences. However, if we have password protected encrypted computers that require a password to wake from sleep or login, have SSH only allowing admin accounts, and decent passwords standards on the client. We are not running unsecure versions of http browsers in ways that were made obsolete 20 years ago. We don't go out and download sketchy illegal software that is likely to have malware or other nastiness in it. The clients should be relatively safe from what I can tell. I wait for somebody to show me a client side attack that does not require the user doing something stupid.

I posted this in one of the other threads maybe it helps http://lcamtuf.blogspot.com.es/2014/09/quick-notes-about-bash-bug-its-impact.html

[ImAMacGuy]

Apple insider just posted this...

http://appleinsider.com/articles/14/09/26/apple-says-most-customers-not-vulnerable-to-shellshock-pat...

[nessts]

Ah another voice of sanity.

[RobertHammen]

The posted patches that @Lotusshaney and @kitzy did include bash 3.2.52, which fixes the CVE-2014-6271 vulnerability, but not CVE-2014-7169. Apparently there is now a bash 3.2.53 which fixes both.

DHCP proof of concept: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

I would imagine that Apple will release a Security Update 2014-xxx for at least Mavericks and Mountain Lion, and would hope that it includes the bash 3.2.53. Lion is teetering on the edge of being unsupported, but it probably gets an update. If you have Snow Leopard and earlier in your environment, you may look to "roll your own" patch as it's unlikely that Apple will patch those older OSes.

[nessts]

If your DHCP administrator does this or your DHCP server gets remote access by an attacker, ShellShock is still the least of your concerns. You fire the Administrator that does something malicious, and you get your firewall and server teams busy figuring out how and why somebody has remote access and why they only chose to use ShellShock to screw with your network as apposed to just doing whatever they want anyway.

[RobertHammen]

But what if a DHCP server at a Starbucks, McDonalds, an airport, etc. becomes compromised? This is not outside of the realm of possibility, and, with the advent of BYOD programs, this becomes a significant security concern.

I agree that the bigger concern is people using Internet-exposed Macs and other Unix systems with mod_cgi/SSI and various scripts. These are the folks who need to be patching ASAP.

On the client side, I'm telling clients to wait to see if Apple does anything by the end of the day. If they have 10.6.8 and earlier, they probably need to roll their own patch and test/deploy it. They should also have their own updates for Lion, Mountain Lion, and Mavericks developed, tested, and ready to go. If Apple doesn't act by the end of the day, they should then consider deploying them.

[nessts]

Then you get free coffee for the rest of your life :) Seriously that's a good point that i had not considered. Then again, if you are really worried about Starbucks or AT&T's infrastructure being hacked what are you doing connecting to it in the first place. You should be using your smart phone and staying off the free wifi and probably getting better speeds anyway.

[Lotusshaney]

Working on the new 3.2.53 version of the installer now !