Security Update: Bash "Shellshock" Vulnerability

jason_vanzanten
New Contributor III

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:

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

34 REPLIES 34

mkremic
New Contributor III

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
Valued Contributor II

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
Contributor

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
New Contributor III

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
Valued Contributor

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
Contributor II

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
Contributor

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
Legendary Contributor II

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
New Contributor

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

systems_support
New Contributor

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
Valued Contributor II

@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
Contributor II

Bendelaat
New Contributor II

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.

jwojda
Valued Contributor II

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
New Contributor II

@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
Valued Contributor

@Bendelaat
Same error here with 10.8.5

jwojda
Valued Contributor II

@Bendelaat 10.8.5 worked for me.

would you mind posting your policy/script?

jwojda
Valued Contributor II

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
Legendary Contributor II

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
Contributor

Has anyone seen this patch come through their SUS yet?

JasonkMiller
New Contributor

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
New Contributor II

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
Valued Contributor

@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
New Contributor II

@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
New Contributor

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

charlesludwick
New Contributor III

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
Valued Contributor II

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

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

mm2270
Legendary Contributor II

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
Valued Contributor

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

mm2270
Legendary Contributor II

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

frozenarse
Contributor II

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

nessts
Valued Contributor II

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
Contributor II

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
Valued Contributor II

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.