Security Update: Bash "Shellshock" Vulnerability

[jason_vanzanten]

Last updated: October 3, 2014

As you may have heard, a significant vulnerability in Bash was announced yesterday, Wednesday, September 24, 2014, commonly referred to as “Shellshock” that affects all versions of Bash through version 4.3:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

The following are links to some external resources with additional details:

http://www.kb.cert.org/vuls/id/252743
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

JAMF Software has investigated the impact of this vulnerability for our customers, and the following is a summary of what we found:

Affected operating systems
It is likely that all un-patched versions of Linux and Unix, including OS X, are affected by this vulnerability.  Details of actual exploits are still emerging, but reports indicate that SSH and web servers with CGI components are likely vectors for perpetrating an attack. The following external blog post lists a variety of "potential exploitation vectors":

https://www.dfranke.us/posts/2014-09-27-shell-shock-exploitation-vectors.html

Windows does not include Bash and, therefore, should not be affected by this vulnerability.

JAMF Software Products and Services

• The JAMF Software Server (JSS) does not rely on Bash or have any CGI components enabled by default, but the server OS that is hosting the JSS could have these items enabled
• The jamf binary and client applications do use shell commands in certain functions, which rely on the native installation of Bash on OS X
• The JAMF Distribution Server (JDS) uses Apache but does not use the CGI module; however, the Apache service or other services may be configured to use the CGI module (mod_cgi)
• Any services on JAMF Cloud that are externally accessible have been patched to use the recommended version of Bash
• Versions of the NetBoot/SUS Appliance OVA through 3.0.1 are built using a version of Ubuntu that includes an affected version of Bash

How to tell if a system is affected
The following external resources are available for testing systems for this vulnerability:

http://serverfault.com/questions/631257/how-to-test-if-my-server-is-vulnerable-to-the-shellshock-bug
https://shellshocker.net/#

Possible fixes
Please follow official vendor recommendations for installing software updates that include a patched version of Bash:

• Ubuntu - http://askubuntu.com/questions/528101/what-is-the-cve-2014-6271-bash-vulnerability-and-how-do-i-fix-...
• Red Hat - https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injecti...
• Apple - http://support.apple.com/kb/ht1222
  • About OS X bash Update 1.0 - http://support.apple.com/kb/HT6495
  • OS X Mavericks (10.9.5 or later) - http://support.apple.com/kb/DL1769
  • OS X Mountain Lion (10.8.5) - http://support.apple.com/kb/DL1768
  • OS X Lion (10.7.5) - http://support.apple.com/kb/DL1767

Additional resources
The JAMF Nation community has started discussion regarding this issue:

https://jamfnation.jamfsoftware.com/discussion.html?id=11909

Feel free to reach out to your Support representative through https://support.jamfsoftware.com/ with any questions, or bookmark this discussion post and check back for any available updates.

Thanks,
Jason Van Zanten
Product Specialist, Information Security JAMF Software

[mkremic]

In response to this i've created a package using JAMF's composer to patch the vulnerable bash and sh versions. Created using Mavericks 10.9.4 and follows these instructions here:

http://mac-how-to.wonderhowto.com/how-to/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x-0157606/

It's a non-flat pkg installer with a perl postflight script to take care of copying the new bash and sh version into /bin

Feel free to dissect it in Composer if you want to be sure! The 2 files (bash & sh) are installed to /private/tmp/bash-fix and then copied to /bin after the originals are backed up with a .old suffix.

I've put it up on my dropbox if anyone wants to try it out and use it in their environment. Have tested on Mavericks and Yosemite Beta and all good.

https://www.dropbox.com/s/0gwor9etpjy4kwk/Shellshock-CVE-2014-6271-Patch-20140926.pkg.zip?dl=0

Cheers

Michael Kremic

[nessts]

How many of us are running http servers with mod_cgi turned on for our clients? Users cannot just get this from what I am seeing. they are going to have to download a malicious script, or package to install to get this on the majority of workstations. I think ShellShock and Awe is in full swing and is being blown way out of proportion. Not to mention the fix that exists only solves one piece of the problem. This http://lcamtuf.blogspot.com.es/2014/09/quick-notes-about-bash-bug-its-impact.html might help understand it better. And maybe I am missing something.

[luispalumbo]

I've just logged in here to mention what I've done to solve it and found that Michael Kremic, mkremic, has done the same thing as me.

Michael, on your script the $oldbash variable is not declared so the $newbash won't replace the $oldbash.

Anyway, thanks for sharing it with all of us.

[mkremic]

Thanks @luispalumbo !

I'd rather be security conscious and patch it then leave it open. Chances of someone actually taking advantage of the exploit on a desktop/laptop are slim but you wouldn't want to be the company that it happened to!

Also, I tested patching 10.9.4 and then applying the Apple update to 10.9.5 and bash is still patched after the update.

[chriscollins]

an EA to get the version on clients so you can target with a smart group if you like.

#!/usr/bin/env bash

bash_version=$(/bin/bash --version | head -n 1 | awk '{print $4}' | sed s/"(1)-release"/""/)

echo "<result>$bash_version</result>"

[lisacherie]

From a redhat kb https://access.redhat.com/articles/1200223

EA to determine vulnerable or ok - so far seeing vulnerable results.

#!/usr/bin/perl -w

my $RESULT=`env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"`;

chomp $RESULT;

if ($RESULT=~/^vulnerable
test$/){
        system "echo '<result>vulnerable</result>'";
}
else {
        system "echo '<result>ok</result>'";
}

[luispalumbo]

Hi guys, the EA I used was something like @chriscollins but a bit simpler. I've also created a smart group to with the old and another with the new version, then created a policy that runs once per computer deploying a package as mentioned above by @mkremic with a Perl script.

This my EA

#!/bin/bash
echo "<result>`bash --version | head -1 | tr "(" " " | awk '{print $4}'`</result>"

[mm2270]

Simplest version I can come up with for an EA in case anyone is interested-

#!/bin/sh

echo "<result>$(bash --version | awk -F'[ |(]' '/version/{print $4}')</result>"

[Summers]

Thanks Michael,
Got the package and it works like a charm. Really appreciate it...!!

[systems_support]

Do not run the package posted by Michael Kremic on any 10.7.x machines. The ones I've run it on fail to boot up after a restart. 10.8.x and 10.9.x work fine though.

[RobertHammen]

@Lotusshaney has posted his pkg, which has versions for 10.8/10.9/10.10 and 10.7/10.6 (which version gets installed is based on postinstall script logic) at:

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

[elliotjordan]

Apple appears to have posted a fix:

10.9 http://support.apple.com/kb/DL1769
10.8 http://support.apple.com/kb/DL1768
10.7 http://support.apple.com/kb/DL1767

[Bendelaat]

Currently setting up fix deployment.

10.8.5 seems to reject the patch.

installer: Cannot install on volume / because it is disabled. installer: This volume does not meet the requirements for this update.

10.7.5 and 10.9.5 are patching correctly.

as anyone seen this behaviour? all software updates are installed, rebooted but no luck.

[ImAMacGuy]

Bendelaat: thank you, I will keep an eye out for it when I start my testing and report back.

A separate question. For deployment of these (assuming all works as expected), if I mark each package with their respective os requirements (BashUpdateLion - requires 10.7.x, BashUpdateMavericks - requires 10.9.x, etc), can I just lump them all into one policy?

Update:
took a smart group from each of the 3 os's assigned all 3 packages to it, and updated it. All 3 packages installed on their respective OS, but also reported as failed for all 3 (2 of the 3 packages didn't meet OS requirements).

@Bendelaat

If you could post your script and policy that would help :)

[Bendelaat]

@jwojda
I don't know about the requirements. i just uploaded the .pkg files to repository and made policy for each with a custom trigger. then a script that tests for specific os versions and calls the appropriate policy.

[dpertschi]

@Bendelaat
Same error here with 10.8.5

[ImAMacGuy]

@Bendelaat 10.8.5 worked for me.

would you mind posting your policy/script?

[ImAMacGuy]

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

Here's the description from Apple's security-announce mailing list (I haven't seen it on HT1222 yet): APPLE-SA-2014-09-29-1 OS X bash Update 1.0 OS X bash Update 1.0 is now available and addresses the following: Bash Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5, OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5 Impact: In certain configurations, a remote attacker may be able to execute arbitrary shell commands Description: An issue existed in Bash's parsing of environment variables. This issue was addressed through improved environment variable parsing by better detecting the end of the function statement. This update also incorporated the suggested CVE-2014-7169 change, which resets the parser state. In addition, this update added a new namespace for exported functions by creating a function decorator to prevent unintended header passthrough to Bash. The names of all environment variables that introduce function definitions are required to have a prefix "_BASH_FUNC<" and suffix ">()" to prevent unintended function passing via HTTP headers. CVE-ID CVE-2014-6271 : Stephane Chazelas CVE-2014-7169 : Tavis Ormandy OS X bash Update 1.0 may be obtained from the following webpages: http://support.apple.com/kb/DL1767 – OS X Lion http://support.apple.com/kb/DL1768 – OS X Mountain Lion http://support.apple.com/kb/DL1769 – OS X Mavericks To check that bash has been updated: Open Terminal Execute this command: bash --version The version after applying this update will be: OS X Mavericks: GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) OS X Mountain Lion: GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin12) OS X Lion: GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin11) Information will also be posted to the Apple Security Updates web site: http://support.apple.com/kb/HT1222

[mm2270]

So, recall that there was a reissue of the 10.8.5 update from Apple. There was the original 10.8.5 and then soon after a "10.8.5 Supplemental Update 1.0" was issued. Its possible for those having trouble installing the bash patch on their 10.8.5 Macs that they never got the supplemental 10.8.5 update installed prior. The OS version number did not change, which may add to the confusion.

I'm just speculating here, since I haven't yet tried installing it on any of our Macs running ML to see what the results are.

[mostlikelee]

Has anyone seen this patch come through their SUS yet?

[JasonkMiller]

Yet to see this come this SUS just yet. I have yet to see when Apple said they are going to add it to SUS.

[casper100]

10.8.5 Bash updates are failing on build 12F37, "Installation failed. The installer reported: installer: Cannot install on volume / because it is disabled. installer: This volume does not meet the requirements for this update".
Successful on build 12F45, so I think Mike is correct about the supplemental update.
10.7 and 10.9 Bash updates are successful, as long as they are at 10.7.5 and 10.9.5 (respectively).

[JPDyson]

@Jmillerlbl Apple doesn't "say" they are/aren't adding patches to SUS, generally speaking. It's typically the case that patches are added to SUS shortly after being released via their own catalog and manual download. The lead time here is a tad on the high side, but no need to panic - it'll be in the catalog soon I'm sure.

[sstone]

@mhamlin I had the same thing happen to my 10.7 machines. Have you had any success getting them back? If so, how did you get the machines back. Thanks

[systems_support]

@sstone You have to boot to recovery (connect to Ethernet then hold command+R before startup chime) and re-install Lion.

[charlesludwick]

Take this at face value, but we had a ticket open with them in regards to this exploit for tracking reasons, and I specifically asked the SUS question. Here is the response.

> This getting released to Software Updates?
>

There are no immediate plans to release these as a software update.

As always, if you have any additional questions or information about this issue, please let me know.

Thanks,
Dan N
AppleCare Enterprise Customer Support Engineering

[CasperSally]

>>There are no immediate plans to release these as a software update. >>

Apple sure is strange with some of the decisions they make.

[mm2270]

Nice. Let's not actually make it easy for Mac users to install this 'security' update.
By not publishing it to SUS, the majority of average Joe Mac users will never even know about this and won't get it installed until and if Apple rolls this into another security update later that does show up in SUS. Or until they upgrade their Mac to Yosemite. Maybe that's the plan. A little birdie told me 10.10 has reportedly gone GM, so shouldn't be long now.

[nkalister]

apple GM or for real GM?
Yes, I AM still miffed about the changes to Mavericks after it went 'GM'. :)

[mm2270]

For real GM. Check macworld.com. There's an article about it.

[frozenarse]

So Apple really isn't going to make this available via Software Update? That seems crazy to me.

[nessts]

its a 3MB package how hard is it to make a policy to just install it? And better yet you can enforce the .5 update that is necessary with it. Seems like what I bought the Casper Suite for is a situation just like this, not sure why you bought it.
And this vulnerability is so unlikely to affect "most" Mac users, and while it makes no sense why they are not putting it in ASU/SUS why worry about the general population. My guess is hearing whats happening on the Gentoo linux distribution (patches every day last week for bash) that the current two fixes are really not all there are, and while its possible to exploit this its still less dangerous than users installing software or running scripts they download off the internet from devious people.

and changes after the last Seed or Beta version have been the norm for over a year now, I would not expect that to change anytime soon.

[frozenarse]

It wouldn't be too hard to handle this with Casper policies. It would be much easier to use my existing SUS infrastructure though. I wouldn't have to create different policies for 10.7/10.8/10.9 if it was in SUS. It just makes more sense to me to handle all OS updates with SUS vs Casper. I also have a bunch of notebooks that are set to look to Apple's SUS servers and install updates automatically. That is nice because a bunch of my users don't make it back to our network frequently to run Casper policies.

I think you make a good point with the linux updates. Perhaps Apple is holding off with putting something out via Software Updates until they know that no new vulnerabilities are uncovered.

[CasperSally]

I built the policy last week and haven't looked back, but I think Apple's choice to not included it in SUS is lame.

What's the worst thing that results, machines that likely aren't vulnerable get a 3MB patch? It needs to be replaced when a new version is available?

Maybe apple doesn't want to publicize to (or remind) their consumer customer base that the vulnerability exists when it shows up for them during software update. Granted, it isn't a huge client vulnerability, but a whole bunch of us are pushing it to clients anyway.