Best practices for patching the bash vulnerability

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

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

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.

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

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.

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

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