Best practices for patching the bash vulnerability

elliotjordan
Contributor III

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.

57 REPLIES 57

luispalumbo
Contributor

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

Lotusshaney
Contributor II

New 3.2.53 version now on my blog

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

iJake
Valued Contributor

@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
Legendary Contributor III

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

RobertHammen
Valued Contributor II

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
Contributor

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
Contributor II

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

iJake
Valued Contributor

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
Contributor III

Thanks @iJake!

clrlmiller
New Contributor III

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
Contributor

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
Legendary Contributor III

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
New Contributor

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

elliotjordan
Contributor III

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
Legendary Contributor III

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
New Contributor III

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
Valued Contributor

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

MichaelC
New Contributor III

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