OS X bash Update 1.0 released for Mavericks, Mountain Lion and Lion

flyboy
Contributor
48 REPLIES 48

Aaron
Contributor II

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.

rderewianko
Valued Contributor II

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

Aaron
Contributor II

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.

Millertime
New Contributor III

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

Millertime
New Contributor III

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/

RyanN
New Contributor

3.2.54 should be the latest bash --version

sean
Valued Contributor

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

aamjohns
Contributor II

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

dpertschi
Valued Contributor

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.

flyboy
Contributor

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.

CasperSally
Valued Contributor II

@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

sean
Valued Contributor

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

ifbell
Contributor

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"

rderewianko
Valued Contributor II

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

CGundersen
Contributor III

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

jschlackman
New Contributor

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.

CasperSally
Valued Contributor II

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

nkalister
Valued Contributor

@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".

aamjohns
Contributor II

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

CSHGreenwich
New Contributor III

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.

jschlackman
New Contributor

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.

nkalister
Valued Contributor

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.

CSHGreenwich
New Contributor III

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.

mm2270
Legendary Contributor III

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

jubei
New Contributor II

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.

nessts
Valued Contributor II

I would think Apple made that requirement for a reason, like its depending on some library that only exists in 10.9.5 or if you are actually security conscious you have the .5 version of the OS so that you have all the other security updates that have been released. Just a guess though.

jubei
New Contributor II

I agree. I was just looking for a quicker way to get this pushed out. Thx.

nessts
Valued Contributor II

make a policy to update machines to .5
make another policy that when a machine is at .5 push the bash update. 10 seconds to do it right, who knows how long to look for a way around right, then testing if your work around really worked and didnt cause some other problem.

jubei
New Contributor II

Yup again agreed. The problem for us is that the .5 OS updates require reboots. Tough to gauge when users will be shutting down if at all. Since most of our Mac users are execs, I'll need to coordinate it a bit more. Thanks for your help.

CSHGreenwich
New Contributor III

@ mm2270 Because it was brainless and easy. Composer would not let me drag the file into Casper Admin as I had not extracted the package.

CasperSally
Valued Contributor II

I made a package on 10.9.5 machine and am pushing it to 10.9.4 machines without issue.

Updating machines to .5 isn't easily done here where students are closing lids on laptops every 30 minutes. And our students almost never reboot as well.

emily
Valued Contributor III
Valued Contributor III

I'm having the same issue right now. Policy with the .pkg for 10.9.5 and 10.8.5 (separate policies, natch) is great, but getting those stragglers up to 10.9.5 is the real challenge. I still haven't found a software update policy that really works in our environment. I need to be able to let people defer on a rolling basis and after a certain amount of attempts, kind of like Window Intune. That may be a whole other issue, though…

aamjohns
Contributor II

Emily,
If you search around you can find scripts that will pretty much let you do the updates the way you are describing. To match exactly what you want might take a little editing, but I do this based on a prompt my users can defer three times and then it is forced. Sorry for going off topic.

dgreening
Valued Contributor II

Anyone apply this patch to their JSS server(s) yet? I have applied it to our DPs but not the main servers as of yet. Outcome if you have patched?

CSHGreenwich
New Contributor III

I patched my OSX 10.6 with JSS 8.73 and it returns version 3.2.53. so far the server has been okay and it is being used today!

chris_kemp
Contributor III

I patched one of our JSS servers this morning, no problems so far.

CSHGreenwich
New Contributor III

I am having a problem with my 10.8.5 smart group reporting the wrong version of the OS.

I used the same criteria for 10.9.5 and that is working but 10.8.5 is not working . Did anyone else see the same.

For 10.9.5, I downloaded on 10.9.5 and then used composer to create a source .

For 10.8.5 I just extracted the package because I did not have 10.8.5 0r 10.7.5 handy???
It says it success but when you check the bash version, it is not updated.

Josh_Smith
Contributor III

You shouldn't need Composer if you are using the Apple supplied patch. Just drag each .pkg (x3 if you have 10.7,8,9.5) into the Casper Admin Window.

I did run into an issue where the 10.8.5 patch would not run on a 10.8.5 machine....it turned out 10.8.5 wasn't enough for the .pkg, it actually wants "10.8.5 with the OS X Mountain Lion 10.8.5 Supplemental Update" http://support.apple.com/kb/DL1686. Apparently 10.8.5.1 would have been too easy.

I ran the 10.8.5 Combo update on the 10.8.5 machine and the patch worked after that.

mm2270
Legendary Contributor III

So, 10.8.5 Supplemental is required, as I speculated here