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.