Posted on 09-29-2014 04:11 PM
Mavericks: http://support.apple.com/kb/DL1769
Mountain Lion: http://support.apple.com/kb/DL1768
Lion: http://support.apple.com/kb/DL1767
Posted on 09-29-2014 04:43 PM
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.
Posted on 09-29-2014 04:57 PM
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.
Posted on 09-29-2014 05:26 PM
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.
Posted on 09-29-2014 06:56 PM
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
Posted on 09-29-2014 07:00 PM
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/
Posted on 09-29-2014 09:48 PM
3.2.54 should be the latest bash --version
Posted on 09-30-2014 02:59 AM
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
Posted on 09-30-2014 05:27 AM
FYI, after patching I too am seeing version 3.2.53(1)-release (x86_64-apple-darwin13) (on Mavericks).
Posted on 09-30-2014 05:41 AM
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.
Posted on 09-30-2014 05:48 AM
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.
Posted on 09-30-2014 05:50 AM
@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
Posted on 09-30-2014 06:03 AM
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
Posted on 09-30-2014 06:29 AM
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"
Posted on 09-30-2014 06:48 AM
Anyone see it in the software update catalogues yet?
Apple says it is...
http://support.apple.com/kb/HT1222
Posted on 09-30-2014 07:04 AM
Nothing on our internal SUS yet. Not seeing it yet as an update on 10.9.5 (vulnerable) client when pointed @ Apple.
Posted on 09-30-2014 08:11 AM
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.
Posted on 09-30-2014 08:24 AM
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
Posted on 09-30-2014 08:32 AM
@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".
Posted on 09-30-2014 08:32 AM
@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.
Posted on 09-30-2014 08:36 AM
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.
Posted on 09-30-2014 08:36 AM
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.
Posted on 09-30-2014 08:40 AM
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.
Posted on 09-30-2014 08:42 AM
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.
Posted on 09-30-2014 08:52 AM
@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.
Posted on 09-30-2014 08:54 AM
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.
Posted on 09-30-2014 08:57 AM
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.
Posted on 09-30-2014 08:59 AM
I agree. I was just looking for a quicker way to get this pushed out. Thx.
Posted on 09-30-2014 09:01 AM
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.
Posted on 09-30-2014 09:05 AM
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.
Posted on 09-30-2014 09:21 AM
@ 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.
Posted on 09-30-2014 09:22 AM
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.
Posted on 09-30-2014 09:29 AM
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…
Posted on 09-30-2014 09:40 AM
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.
Posted on 09-30-2014 09:40 AM
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?
Posted on 09-30-2014 11:18 AM
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!
Posted on 09-30-2014 11:23 AM
I patched one of our JSS servers this morning, no problems so far.
Posted on 09-30-2014 12:45 PM
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.
Posted on 09-30-2014 02:00 PM
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.
Posted on 09-30-2014 02:16 PM
So, 10.8.5 Supplemental is required, as I speculated here