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.

[luispalumbo]

Check the following post https://jamfnation.jamfsoftware.com/discussion.html?id=11914 for information on how to fix it using EA and policies.

[Lotusshaney]

New 3.2.53 version now on my blog

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

[iJake]

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

[mm2270]

Its a package within the package that contains the binaries. Crack it open with something like Pacifist and you'll see it.

[RobertHammen]

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

[seabash]

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 ;)

[Lotusshaney]

thanks @seabash for spotting the chown, I have changed my package to reflect root:wheel.

[iJake]

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

[elliotjordan]

Thanks @iJake!

[clrlmiller]

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

[seabash]

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.

[mm2270]

As for an EA, I think its easier to simply pull the version of bash (patched version is the same for all 3 OSes Apple released patches for) and then echo a result.
For example-

#!/bin/sh

if [[ $(bash --version | awk -F'[ |(]' '/version/{print $4}') == "3.2.53" ]]; then
    echo "<result>Patched</result>"
else
    echo "<result>Unpatched</result>"
fi

[mmartinez]

What would be the best criteria to use when searching for computers that don't have the patch?

[elliotjordan]

Given that Apple's patches require 10.7.5, 10.8.5, or 10.9.5 respectively, I'm going to use that as the criteria.

• Smart group for 10.7.0-10.7.4 scoped to policy for prompting employees to install 10.7.5.
• Smart group for 10.8.0-10.8.4 scoped to policy for prompting employees to install 10.8.5.
• Smart group for 10.9.0-10.9.4 scoped to policy for prompting employees to install 10.9.5.
• Smart group for 10.7.5 scoped to policy for installing 10.7 bash update, run once per computer.
• Smart group for 10.8.5 scoped to policy for installing 10.8 bash update, run once per computer.
• Smart group for 10.9.5 scoped to policy for installing 10.9 bash update, run once per computer.
• "Update inventory at startup" policy to catch computers after OS updates and reclassify them in the smart groups.

[mm2270]

Personally, I would create an EA to grab the bash version string. I know some others have more complex EA scripts that run tests and check the output, but I don't see the need for that. If the bash version is at 3.2.53 then its OK.

Here is an EA script you can use if you choose to do that

#!/bin/sh

if [[ $(/bin/bash --version | awk -F'[ |(]' '/version/{print $4}') == "3.2.53" ]]; then
    echo "<result>Patched</result>"
else
    echo "<result>Unpatched</result>"
fi

Another way in an EA would be to convert to integer and do an equal or greater than comparison. That may be safer since its also possible that bash could be at a slightly higher version at some point down the line on some Macs.

#!/bin/sh

if [[ $(/bin/bash --version | awk -F'[ |(]' '/version/{print $4}' | tr -cd [:digit:]) -ge "3253" ]]; then
    echo "<result>Patched</result>"
else
    echo "<result>Unpatched</result>"
fi

[clrlmiller]

Well, the crux of the exploit is a bug which allows the running of a BASH command immediately after setting a variable and before an intended BASH command. This video explains it in Nutshell fashion: https://www.youtube.com/watch?v=ArEOVHQu9nk

The Extension Attribute I'd posted yesterday actually tests for this bug and determines if the issue is still present in the BASH version presently being used and outputs the result. Some others have posted other Ext Attrib which look for the version of BASH installed which follows the logic of "if it's not the latest version, then it's vulnerable". Which makes sense in a way, but I didn't care about the version level; just if the issue is present. You could use mine, or anyone else's Extension Attribute. It really depends on what you're looking to determine.

[JPDyson]

I think it happens to be easier to check for the actual exploit, rather than the bash version... but I do both.

[MichaelC]

GNU Bash is already up to 3.2.55. Any bets on 3.2.56?