Anyone know if this will come through software updates, or does it need to be applied manually? It's not listed in the available software list for me.

I'd assume they just haven't posted it to the sw update catalogue yet, as if you look at the KB'S they haven't actually listed it on the security page yet.

http://support.apple.com/kb/HT1222

Ah ok. Well I got impatient and just created policies to push it out automatically. They do require the latest version of the relevant OSX to be installed (ie; 10.8.5, 10.9.5) otherwise it will fail.

Testing this now... Does anyone know how to verify whether or not the update was successful? Unfortunately I'm running the beta OS on my MBA at home, and I wasn't able to find any helpful info from Apple's that may answer that question.

Thanks,
Bill

After some more research the answer appears to be found on this site. If anyone could confirm tonight that would be awesome. Otherwise I'll do so tomorrow when I'm back in the office.

"When installed on an OS X Mavericks system, the patch upgraded the Bash shell from version 3.2.51 to version 3.2.53..."

http://arstechnica.com/apple/2014/09/apple-patches-shellshock-bash-bug-in-os-x-10-9-10-8-and-10-7/

3.2.54 should be the latest
bash --version

After applying Apple's update, I'm seeing:

10.7.5

echo ${BASH_VERSINFO[@]}

3 2 53 1 release x86_64-apple-darwin11

10.9.5

echo ${BASH_VERSINFO[@]}

3 2 53 1 release x86_64-apple-darwin13

Not 3.2.54 as suggested by newporr

FYI, after patching I too am seeing version 3.2.53(1)-release (x86_64-apple-darwin13) (on Mavericks).

So, reading between the lines so to speak… It looks like we can safely assume that 10.9.5 is the last update.

Patches are usually released for all minor versions of an actively developed major version. Since they're calling out 10.9.5 specifically in the requirements for this bash patch, I'd say that's end of the road. Which blows because I've not deployed .5 due to the iffy can't-login-again-if-AD-bound bug.

Grrrrr.

Not looking to hijack the thread, but talk to me about the can't-login-agin-if-AD-bound bug. I had decided to skip .5 for different reasons, but now don't have a choice. I'm asking because I have regular issues with my machines "falling off" AD. I have to unbind and rebind. Grrrr indeed.

@Berrier][/url @dpertschi][/url - someone on mac ent list said they opened the update (with pacificst) and edited the script looking for 10.9.5 to install it on earlier versions. I haven't gotten a chance to do this yet

Alternatively, you could probably just install on a single 10.9.5 machine and compose a pkg to deploy to earlier 10.9 versions. Same for earlier OS versions if you have a similar issue with running the latest on those.

I imagine the only difference between these versions anyway is the reported version, eg:

10.7

echo ${BASH_VERSINFO[5]}

x86_64-apple-darwin11

10.9

echo ${BASH_VERSINFO[5]}

x86_64-apple-darwin13

In case anyone is interested this is the bit of script I have been using to test the failure and the fix.

env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"

Anyone see it in the software update catalogues yet?
Apple says it is...
http://support.apple.com/kb/HT1222

Nothing on our internal SUS yet. Not seeing it yet as an update on 10.9.5 (vulnerable) client when pointed @ Apple.

I created a policy to push out the .pkg, and while it reports as successfully installed in JSS, it has no effect on the bash version reported compared to a base 10.9.5 install, nor does it pass a vulnerability test via script (even after restarting, just in case).

I've replicated this on several machines now: only when I manually install is there any change. Anyone else seeing this issue?

bash-3.2$ bash --version

GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)

Copyright (C) 2007 Free Software Foundation, Inc.

bash-3.2$ sudo jamf policy

Password:

Checking for policies triggered by "recurring check-in"...

Executing Policy OS X bash Update 1.0...

    Mounting Distribution to /Volumes/CasperShare...

    Verifying package integrity...

    Installing OS X bash Update 1.0 - OS X Mavericks.dmg...

    Closing package...

Submitting log to https://jss.mcleanschool.org:8443/

Unmounting file server...

bash-3.2$ bash --version

GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)

Copyright (C) 2007 Free Software Foundation, Inc.

Does your policy update inventory? Mine is updating via policy ok.

edit- nevermind - should've read your post more closely. I thought you were gathering via ext attrib

@jschlackman- you need to install the pkg that's inside the DMG. From that log it looks like your policy is just mounting the DMG and copying the contents out, so the pkg is not actually being run and bash is not being updated. That's why you're seeing the old versions after the "install".

@jschlackman,
It is working for me. I downloaded each .dmg, drug out the .pkg, uploaded with Casper Admin, and then created smart groups for OS 10.9.5, 10.8.5, and 10.7.5 and then created policies using the respective .pkg for each OS version.

Once it runs, the systems are no longer vulnerable and the bash version changes as I noted in another post above.

I created a policy to push out the .pkg

Correct me if I am wrong, but it looks like you are using the .dmg, not the .pkg.

I created Smart groups based on the OSX version. the scope for the policy has been set to the appropriate Smart group. I did one manual install and found out that the install reports as successful but the bash version does not appear to be updated.
Upon further investigation I found that the OSX was 10.9.3 not 10.9.5. Once completing the update to Mavericks, I reran the install and the BASH version updated properly. I am now working on Mountain Lion.

You guys are spot on about the .dmg. I even knew this, and already extracted the .pkg... and then uploaded the wrong file.

It's been one of those months.

Sean-- it is 3.2.53, but it's a custom version that includes the namespace fix that Florian from redhat suggested and was integrated into gnu's 3.2.54. Testing on mavericks machines patched with apple's patch show that the mac is NOT vulnerable to CVE-2014-7169, which is the issue that 3.2.54 fixed. The only remaining issue is that apple's patch doesn't fix the crash bug being tracked under CVE-2014-7186.

I've been using a script from github to check for status on all the various shellshock issues: https://github.com/hannob/bashcheck

Output from that on a patched mavericks machine:

kalisten-ZFD58:~ kalisten$ /Users/kalisten/Dropbox/bashcheck.sh 

Not vulnerable to CVE-2014-6271 (original shellshock)

Not vulnerable to CVE-2014-7169 (taviso bug)

/Users/kalisten/Dropbox/bashcheck.sh: line 18: 34349 Segmentation fault: 11  bash -c "true $(printf '<<EOF %.0s' {1..79})" > /dev/null 2>&1

Vulnerable to CVE-2014-7186 (redir_stack bug)

Test for CVE-2014-7187 not reliable without address sanitizer

Variable function parser inactive, likely safe from unknown parser bugs

The segmentation fault is NOT an error in the script, that's the indication that -7186 is not yet patched.

I download the package . Drag it into the bottom section of composer and created a source pkg.

It is working like a charm. I am so happy that I learned that trick in Composer.

@CSHGreenwich - why? I hope you were only doing that to examine the package contents out of curiosity, because there's no need to convert the package to source for distribution to clients.

Is it at all possible through Composer or Pacifist to remove the OS req (10.9.5, etc) from pkg? I have not finished testing 10.9.5 in our environment and don't feel comfortable updating to 10.9.5 then the BASH patch.