Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

How to Test Bash for Shellshock Vulnerabilities

As the ripples from the Shellshock vulnerability spread, an increasing number of problems are being found in the Bash shell, and those problems are being fixed. Apple got into the game with OS X Bash Update 1.0, which explicitly addresses several of the bugs, and may address others (see “Apple Updates Bash for the Shellshock Vulnerability,” 29 September 2014). In this article, I plan to keep track of the vulnerabilities and how you can test to determine if the copy of Bash running on your system — OS X or not — is vulnerable. Thanks to Derek Currie for the idea!

Security vulnerabilities are described and referenced in the CVE (Common Vulnerabilities and Exposures) system, which is run by MITRE Corporation, with funding from the National Cyber Security Division of the U.S. Department of Homeland Security. Every vulnerability is assigned a unique CVE identifier, although merely having a CVE number doesn’t mean that the vulnerability will appear in the National Vulnerability Database run by the National Institute of Standards and Technology — it may turn out to be a duplicate, or its public release may be embargoed until the company in question has a chance to fix the underlying problem.

As of this writing, there are six CVEs surrounding Bash. I’m not going to attempt to describe each of these, since the details are too technical to be useful, but for each I’ll give a test that you can copy and paste at the command line to see if your copy of Bash is vulnerable. Note that there are a number of versions of Bash still in use, including 2.0, 3.1, 3.2, 4.0, 4.1, 4.2, and 4.3 — all are receiving patches. Apple uses Bash 3.2 in OS X 10.9 Mavericks. To learn which version of Bash you have, use this command:

bash --version

Please excuse some of the repetition below — I’m going more for clarity and accuracy than smooth reading.

CVE-2014-6271 -- Apple’s OS X Bash Update 1.0 explicitly says that it addresses CVE-2014-6271. To test CVE-2014-6271, copy the line below and paste at the Unix prompt.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If your copy of Bash is vulnerable, you’ll see:

vulnerable this is a test

And if your copy has been patched successfully, you’ll see only:

this is a test

In my testing of patched (3.2.53) and unpatched (3.2.51) copies of Bash in Mavericks, I get exactly these results.

CVE-2014-7169 -- Again, Apple says that it has patched CVE-2014-7169 with OS X Bash Update 1.0. To test CVE-2014-7169, run the following line in Bash.

env X='() { (a)=>\' sh -c "echo date"; cat echo; rm ./echo

If your copy of Bash is vulnerable, you’ll see:

sh: X: line 1: syntax error near unexpected token `=' sh: X: line 1: `' sh: error importing function definition for `X' Tue Sep 30 11:14:49 EDT 2014

However, if your copy of Bash has been patched successfully, you’ll see only:

date cat: echo: No such file or directory rm: ./echo: No such file or directory

In my testing of patched (3.2.53) and unpatched (3.2.51) copies of Bash in OS X 10.9 Mavericks, I get exactly these results.

CVE-2014-6277 and CVE-2014-6278 -- These two exist because of incomplete fixes for the previously mentioned vulnerabilities. To test for both, use this command:

foo='() { echo not patched; }' bash -c foo

If your copy of Bash is vulnerable, you’ll see:

not patched

And if your copy of Bash has been patched to address the incomplete fixes, you’ll get:

bash: foo: command not found

My patched (3.2.53) copy of Bash in Mavericks passes with flying colors, whereas an unpatched (3.2.51) copy of Bash fails the test. So even though Apple doesn’t mention CVE-2014-6277 and CVE-2014-6278 in its release notes, it appears that the OS X Bash Update 1.0 patches Bash successfully for them.

CVE-2014-7186 -- Apple also says nothing about CVE-2014-7186 in its release notes, and this one proves tricky to test in OS X, since a number of the tests I found return identical successful results in both patched (3.2.53) and unpatched (3.2.51) copies of Bash in Mavericks.

Luckily, Eric Blake of Red Hat runs through a number of these tests for CVE-2014-7186 before settling on this one.

bash -c "export f=1 g='() {'; f() { echo 2;}; export -f f; bash -c 'echo \$f \$g; f; env | grep ^f='"

If your copy of Bash is vulnerable, you’ll see something like the following:

bash: g: line 1: syntax error: unexpected end of file bash: error importing function definition for `g' 1 2 f=1 f=() { echo 2

Blake says that there are two possible successful results if your copy of Bash is immune to Shellshock:

1 () { 2 f=1

and

1 () { f: bash: f: command not found f=1

The first of the successful results is what I see on a patched (3.2.53) copy of Bash in Mavericks, whereas an unpatched (3.2.51) copy of Bash fails the test. So again, even though Apple doesn’t call out CVE-2014-7186 in its release notes, it appears that the OS X Bash Update 1.0 patches Bash successfully for it.

CVE-2014-7187 -- Again going unmentioned in Apple’s release notes, CVE-2014-7187 is the most troubling of the vulnerabilities from the testing standpoint. To test, invoke this command, being sure to remove the line break first:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

If your copy of Bash is vulnerable, you’ll see:

CVE-2014-7187 vulnerable, word_lineno

What’s not clear to me is what will happen if your copy of Bash has been patched successfully. I’ve run this on patched (3.2.53) and unpatched (3.2.51) copies of Bash in Mavericks, and in a patched copy (4.1.2) in CentOS 6.5, all with the same results — nothing happened anywhere. That could mean that the test is flawed when running on Bash 3.2.5x in OS X, and thus doesn’t provide accurate results, or it could mean that the older 3.2.51 in OS X was never vulnerable. If you find a better test for this vulnerability, let me know.

Shellshocker Web Testing -- I’ve heard that Web servers are particularly vulnerable to Shellshock, via CGIs that rely on Bash. The Shellshocker Web site has a tool that allows you to test any given CGI on your Web server, and provides an example CGI that’s designed to be vulnerable if Bash on the targeted server hasn’t been patched.

Unfortunately, I didn’t have a known vulnerable server to test against, and all the tests I ran against my server were inconclusive. So I’d encourage you to give this tool a try, but be sure to test before and after patching, if possible, to see if there’s a difference in the results.

Shellshock Will Continue -- I fear that new vulnerabilities will be discovered in Bash and we’ll see new patches. Apple was careful to give the OS X Bash Update a 1.0 version number; it’s entirely likely we’ll see that number increasing over time.

 

PDFpen is your Swiss Army knife for PDFs. Slice and dice with tools
for reviewing, editing, signing, redacting, and exporting to Word.
With v.8 use digital signatures, and view file & audio attachments.
Solve your PDF dilemmas, try PDFpen. <http://smle.us/pdfpen8-tb>
 

Comments about How to Test Bash for Shellshock Vulnerabilities
(Comments are closed.)

These tests are not runnable because the quotation marks are slanted; programming languages use ambidextrous quotes.
Josh Centers  An apple icon for a TidBITS Staffer 2014-09-30 13:22
That should be fixed now. Try it again, Dave.
Adam Engst  An apple icon for a TidBITS Staffer 2014-09-30 13:33
Sorry about that - the BBEdit text factory we use to curl the quotes is so ingrained in my fingers that I invoked it without even noticing, despite having left a comment at the top for editors to avoid using it. :-)
Paul Schinder  2014-09-30 13:59
I don't quite get the last one, either. I patched a few days ago by grabbing the bash-4.3 source from ftp.gnu.org (and the 27 patches to it). All of the other tests work fine with my new bash. The for loops before the pipe to bash sends out a series of 200 nested for loops that don't do anything. Probably the off-by-one the CVE talks about causes something to go screwy with the execution. The || just means "if the thing on the left returns a status of 0 (successful), then don't do this, otherwise do it" so it won't say anything unless the for ... | bash fails somehow.
Adam Engst  An apple icon for a TidBITS Staffer 2014-09-30 14:09
Yeah. There's a comment at

http://openwall.com/lists/oss-security/2014/09/25/32

about it being visible only with an address sanitizer, which I totally don't understand. But the implication is that it's been patched.
Derek Currie  An apple icon for a TidBITS Contributor 2014-09-30 18:36
This is GREAT Adam! I'm very much enjoying the interactive support within the Mac community regarding the Bash bugs. We have a terrific gestalt. Among them are yourself and Rich Mogul!
Adam Engst  An apple icon for a TidBITS Staffer 2014-09-30 18:57
You're very welcome! Your list gave me the idea, since I'd been hunting down all these tests to see what Apple's patch really did anyway, and it was getting difficult to keep it all straight.
Al Varnell  2014-10-01 01:43
Since Apple added the requirement for prefix "__BASH_FUNC<" and suffix ">()” to prevent unintended function passing via HTTP headers, some of your tests need to be modified to include those in order to accurately test for the vulnerability since exploiters will use them to bypass Apple's "inadvertent" fix.
Adam Engst  An apple icon for a TidBITS Staffer 2014-10-01 09:45
Interesting! Do you have suggestions for or pointers to better tests? I have no shell script experience worth talking about, so this article was based on research, not personal knowledge.
Stan Hoffman  2014-10-06 18:04
If all of this bash stuff is complete gibberish to you, is it still important to "patch bash"?
Adam Engst  An apple icon for a TidBITS Staffer 2014-10-06 18:13
It's not a bad idea to do so, since all you have to do is download Apple's OS X Bash Update 1.0 and run an installer. But if your Mac is behind an AirPort base station and you haven't opened any ports up for Internet services, the chances of an attack getting through are low. Check out our first article on the topic, before the update was available.

http://tidbits.com/article/15105
Stan Hoffman  2014-10-06 20:04
I have a modem and a router (non-Apple). Is this the same?
Adam Engst  An apple icon for a TidBITS Staffer 2014-10-07 10:07
Yes, you're probably safe, but honestly, you've put more work into making these comments than downloading and installing the OS X Bash Update would take. :-) Just update and then you know you don't have to worry.
Karen Kirtland  2014-10-06 19:03
I put the patch in place, and ran the vulnerability tests. All were fine except for CVE-2014-7186. The response was "undefined variable". I even copied it out in a blank Pages document to make sure there weren't extra spaces, etc. I still get "undefined variable". What am I doing wrong? Mavericks 10.9.5, mini.
Harmon Abrahamson  2014-10-07 00:35
Like Karen, I also get
f: Undefined variable.
as a response to the test for CVE-2014-7186. I have already applied the patch, running Mavericks.
Adam Engst  An apple icon for a TidBITS Staffer 2014-10-07 12:26
Very weird - I can't replicate on any of my Macs, patched or unpatched. Are you copying from this page or from the email issue? I'd guess something is being munged in the copy process.
Karen Kirtland  2014-10-08 14:05
I even tried manually typing the string, and still get "undefined variable". Maybe I'll try from the email later.
Marcia Blake  2014-10-07 09:05
Many thanks for all your work on these bash issues, Adam. Your article, "Apple Updates Bash for the Shellshock Vulnerability," (http://tidbits.com/e/15115) provided a link to Jorge Chamorro's modified version-checking script for Snow Leopard users (http://hacksagogo.wordpress.com/2014/10/02/shell-shock-os-x-bash-update-installer-for-snow-leopard/). I ran that and then ran the tests, getting the clean results you showed in this article. Good on ya, mate!
Instructions for updating OSX 10.5 (Leopard) webservers:

http://www.toki.co.nz/apple/2014/09/23-fix-for-shell-shock-on-os-x-105-leopard/
Tommy Friedmann  2014-10-12 15:28
Waited until today to update. There is nothing on Software Update and no link to an updater from the Apple site either. I had saved the link from the date of publication.
Read somewhere else that it was more complicated.
Adam Engst  An apple icon for a TidBITS Staffer 2014-10-13 19:36
Apple has not pushed OS X Bash Update 1.0 out via Software Update, so the only way to get it is via the direct download. There's nothing wrong with doing that - it's just another step or to to install.