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.
- Home
- Community
- Get Support
- General Discussions
- Best practices for patching the bash vulnerability
Best practices for patching the bash vulnerability
- September 25, 2014
- 57 replies
- 0 views
Show first post
57 replies

- Contributor
- 40 replies
- September 25, 2014
#!/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.

- New Contributor
- 14 replies
- September 25, 2014
@ tron_jones
Thank you, much appreciated!
- Contributor
- 279 replies
- September 25, 2014
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>"
- Jamf Heroes
- 339 replies
- September 26, 2014
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?
- Esteemed Contributor
- 1310 replies
- September 26, 2014
@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".

- Contributor
- 116 replies
- September 26, 2014
@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.

- Valued Contributor
- 1007 replies
- September 26, 2014
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
- Esteemed Contributor
- 1310 replies
- September 26, 2014
Apple insider just posted this...
- Esteemed Contributor
- 1027 replies
- September 26, 2014
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.

- Valued Contributor
- 1007 replies
- September 26, 2014
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.
- Esteemed Contributor
- 1027 replies
- September 26, 2014
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.

- Valued Contributor
- 1007 replies
- September 26, 2014
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.

- Contributor
- 96 replies
- September 26, 2014
Working on the new 3.2.53 version of the installer now !

- Contributor
- 45 replies
- September 26, 2014
Check the following post https://jamfnation.jamfsoftware.com/discussion.html?id=11914 for information on how to fix it using EA and policies.

- Contributor
- 96 replies
- September 26, 2014
New 3.2.53 version now on my blog
- Contributor
- 279 replies
- September 26, 2014
@Lotusshaney I cracked open the package but only see the postinstall script that does the moving around of the different BASH versions. Can you explain where you are getting the updated binaries from? Or am I just missing something?
- Legendary Contributor
- 7880 replies
- September 26, 2014
Its a package within the package that contains the binaries. Crack it open with something like Pacifist and you'll see it.
- Esteemed Contributor
- 1027 replies
- September 26, 2014
pkgutil --expand bash_3.2.53.pkg bashfix
Then look at the pkg in the bashfix folder. You'll see binaries for 10.7 and 10.6, and ones marked 10.9 (which also work on 10.8 and, most likely, Yosemite).
The postinstall script looks like this:
#!/bin/zsh
#bash 3.2.53 replacment
#v2.0 - Added rename of old bash and sh to reflect there version - Daniel Shane 26/09/14
swv=sw_vers -productVersion | cut -d . -f 1,2 | sed 's/.//g'
install_dir=dirname $0
currentbash=/bin/bash --version | head -n 1 | awk '{ print $4}' | sed -e 's/(1)-release//g'
currentsh=/bin/sh --version | head -n 1 | awk '{ print $4}' | sed -e 's/(1)-release//g'
if [ $swv -lt 106 ]; then
logger "bash_replacment : Unsupported OS Version Detected"
exit 1
fi
if [ $swv -gt 1010 ]; 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.$currentbash mv "$3"/bin/sh "$3"/bin/sh.$currentsh cp "$install_dir"/10.9/bash "$3"/bin/ cp "$install_dir"/10.9/sh "$3"/bin/ chmod a-x "$3"/bin/bash.$currentbash chmod a-x "$3"/bin/sh.$currentsh 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.$currentbash
mv "$3"/bin/sh "$3"/bin/sh.$currentsh
cp "$install_dir"/10.7/bash "$3"/bin/
cp "$install_dir"/10.7/sh "$3"/bin/
chmod a-x "$3"/bin/bash.$currentbash
chmod a-x "$3"/bin/sh.$currentsh
chown root:staff "$3"/bin/bash
chmod 555 "$3"/bin/bash
chown root:staff "$3"/bin/sh
chmod 555 "$3"/bin/sh
fi

- New Contributor
- 49 replies
- September 27, 2014
Thanks to @Lotusshaney][/url for sharing—even if just to view your method and pkg.
I changed all postinstall `chown` instances to root:wheel, per default perms for other shells in /bin/.. Also, root is member of both staff (GID: 20) and wheel (GID: 0) groups, but pretty sure we want the latter.
For those posting about whether/not they're manually patching or waiting for Apple; consider whether you list your organization in JAMFnation profile. Don't mean to fan flames of panic, but elementary deduction applies here ;)

- Contributor
- 96 replies
- September 27, 2014
thanks @seabash for spotting the chown, I have changed my package to reflect root:wheel.
- Contributor
- 279 replies
- September 29, 2014
The patches from Apple for Mavericks, Mountain Lion and Lion are out.
10.9 http://support.apple.com/kb/DL1769
10.8 http://support.apple.com/kb/DL1768
10.7 http://support.apple.com/kb/DL1767

- Contributor
- 25 replies
- September 30, 2014
I cobbled this Extension Attribute together quickly to gain a sense of what isn't and is patched up in our environment. I'm sure somebody has done or will do this better. But it works for targeting those systems either vulnerable or completely uncertain. You can use this in conjunction with a simple "Operating System" like statement in a Smart Group. Anyway, maybe this'll help somebody.
#!/bin/sh
#
############################################################################
#
# Extension Attribute checks status of Shell Shock vulnerability.
#
############################################################################
ShellShockStatus=env x='() { :;}; echo vulnerable' bash -c 'echo' | grep vulnerable
if [ "$ShellShockStatus" = "vulnerable" ]
then
echo "<result>$ShellShockStatus</result>"
exit 0
else
ShellShockStatus="Patched"
fi
echo "<result>$ShellShockStatus</result>"
exit 0
Here: I cleaned it up a bit and made it smaller.
#!/bin/sh
##################################################################
# Extension Attribute checks status of Shell Shock vulnerability.
##################################################################
ShellShockStatus=`env x='() { :;}; echo vulnerable' bash -c 'echo' | grep vulnerable`
if [ "$ShellShockStatus" != "vulnerable" ]
then
ShellShockStatus="Patched"
fi
echo "<result>$ShellShockStatus</result>"
exit 0

- New Contributor
- 49 replies
- September 30, 2014
Adding to @iJake][/url post... Apple's "OS X Bash Update 1.0" implies Apple expects a bit of bandaging as/if bash sustains any further blows (puns abound).
Also, those manually compiled pkgs/methods (discussed above) should be useful if you have Mac OS X 10.6 client/server in your environment.
Reply
Related topics
Applescript with "do shell script 'chown...'" failsicon
General DiscussionsAppleScript - Deploying Through Jamf Proicon
General DiscussionsMigration from old AD Domain to new Domainicon
General Discussionsstandard user reconicon
General DiscussionsTrouble Adding Computer Description In AD With Applescripticon
General Discussions
Most helpful members this week
- mvu
15 likes
- Chubs
15 likes
- dan-snelson
15 likes
- ThomM
10 likes
- tommypatzius
9 likes
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Scanning file for viruses.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKThis file cannot be downloaded
Sorry, our virus scanner detected that this file isn't safe to download.
OKCookie policy
We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.
Cookie settings
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.