80

How can I ensure my Bash installation is not vulnerable to the ShellShock bug anymore after the updates?

3
  • Please note there are two other vulnerabilities in bash still unpatched (CVE-2014-7186 and CVE-2014-7187). Sep 27, 2014 at 18:39
  • Patches that fix CVE-2014-7186 and CVE-2014-7187 are available as of not long after Deer Hunter posted his comment. If you have a distro provided patch for CVE-2014-7169 you may already have enough to block 7186/7187, test your system with the below commands and see. Also check for any more security updates for your distro. Sep 29, 2014 at 7:44

6 Answers 6

83

To check for the CVE-2014-6271 vulnerability

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

it should NOT echo back the word vulnerable.


To check for the CVE-2014-7169 vulnerability
(warning: if yours fails it will make or overwrite a file called /tmp/echo that you can delete after, and need to delete before testing again )

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

it should say the word date then complain with a message like cat: echo: No such file or directory. If instead it tells you what the current datetime is then your system is vulnerable.


To check for CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

it should NOT echo back the text CVE-2014-7186 vulnerable, redir_stack.


To check for CVE-2014-7187

(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"

it should NOT echo back the text CVE-2014-7187 vulnerable, word_lineno.


To check for CVE-2014-6277. I'm not 100% sure on this one as it seems to rely on a partially patched system that I no longer have access to.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

A pass result on this one is it ONLY echoing back the text testing CVE-2014-6277. If it runs perl or if it complains that perl is not installed that is definitely a fail. I'm not sure on any other failure characteristics as I no longer have any unpatched systems.


To check for CVE-2014-6278. Again, I'm not 100% sure on if this test as I no longer have any unpatched systems.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

A pass for this test is that it should ONLY echo back the text testing CVE-2014-6278. If yours echoes back hi mom anywhere that is definitely a fail.

5
  • 1
    Can we add the general test foo='() { echo not patched; }' bash -c foo to this? Until function exports are put in a separate namespace, we won't stop running from one parser bug to the next.
    – billyw
    Sep 29, 2014 at 15:19
  • Does that test have a CVE? Do you have any references to describe this problem? Also this sort of info may belong on one of the other questions about shellshock due to this Q being about how to test the success or failure of existing patches. Sep 29, 2014 at 23:13
  • That's from Michal Zalewski's blog post on some upcoming Shellshock CVE's (lcamtuf.blogspot.com/2014/09/…). It's his suggested test for CVE-2014-6278, which is still non-public. It seems I was wrong about the test's generality, though; I've already encountered a case where Zalewski's test passed but the CVE-2014-7187 test failed.
    – billyw
    Sep 30, 2014 at 15:51
  • And here is the full disclosure on CVE-2014-6277 and CVE-2014-6278, along with commands to check for them: seclists.org/fulldisclosure/2014/Oct/9
    – billyw
    Oct 2, 2014 at 15:31
  • One point of note: even if the version of BASH is vulnerable, if nothing uses it (i.e. all accounts used by daemons, such as "www" or "cups" or whatever) are configured with BASH as their default shell, and none of your codes calls system() or the like, having the vulnerable version may be less risky, but still, upgrade BASH as soon as possible.
    – DTK
    Oct 27, 2014 at 5:40
32

Export a especially crafted environment variable that will be evaluated automatically by vulnerable versions of Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Now execute a simple echo to see if Bash will evaluate the code in $testbug even though you've not used that variable yourself:

$ bash -c "echo Hello"
VULNERABLE
Hello

If it shows the "VULNERABLE" string, the answer is obvious. Otherwise, you don't need to worry and your patched version of Bash is OK.

Please note multiple patches have been released by the major Linux distributions and sometimes they don't fix the vulnerability completely. Keep checking the security advisories and the CVE entry for this bug.

3
  • 5
    In addition to CVE-2014-6271, the incomplete fix from Red Hat in particular has its own that is also worth following: CVE-2014-7169.
    – DocMax
    Sep 25, 2014 at 19:28
  • 3
    One-liner that doesn't pollute your shell env and happens to work even if 'youre using an alternate login shell (which may not know about export): env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
    – Lloeki
    Sep 26, 2014 at 7:15
  • 1
    There's some Ubuntu specific details here askubuntu.com/questions/528101/… - personally I had to upgrade from Ubuntu 13.10 to 14.04 to fix the issue Sep 26, 2014 at 11:32
2

ShellShock is practically a conjunction of more than one vulnerabilities of bash, and at this moment there is also malaware that exploits this vulnerability, so ShellShock can be an issue that is still open, there is a thread with updates from RedHat about this issues.

Redhat recommeds the following:

Run command:

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

If output is:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

you don't have any fix.

If output is:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

you have CVE-2014-6271 fix

If your output is:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

you are not vulnerable.

The other part of ShellShock check is the CVE-2014-7169 vulnerability check ensures that the system is protected from the file creation issue. To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

If your system is vulnerable, the time and date will display and /tmp/echo will be created.

If your system is not vulnerable, you will see output similar to:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory
2

I wrote a CLI utility called ShellShocker to test your webserver for vulnerabilities on CGI scripts. To test your site, you'd run:

python shellshocker.py <your-server-address>/<cgi-script-path>

ie

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

EDIT: this utility's been taken down, sorry :'(

4
  • Your link is dead
    – SSK
    Sep 26, 2014 at 17:24
  • @SSK Sorry ;) Mistype. Sep 26, 2014 at 17:26
  • Your link is still dead.
    – Mxx
    Sep 30, 2014 at 19:24
  • Yep, sorry, I took it down. It was being exploited in ways I didn't like. Oct 2, 2014 at 5:24
1

You can submit your CGI URL to this online test:

http://shellshock.iecra.org

3
  • 4
    It is polite to provide reasons for downvotes.
    – David
    Sep 26, 2014 at 1:14
  • 4
    "We log all scans"??? Creepy. I'd download the python and run it myself.
    – Brad
    Sep 26, 2014 at 1:54
  • 1
    @brad at least they're telling you. I'm sure that if I was providing a whitehat security service that offered this service I might well keep a log (if only a counter with no individual details) of how many people blindly entered their site details into a website that said it was going to attempt a penetration test, without knowing much about the authenticity of the site offering the test... and they'd want a log of who tested what in case someone used their service to find vulnerable sites belonging to others, too...
    – Rob Moir
    Sep 26, 2014 at 7:52
-1

type env x='() { :;}; echo vulnerable' bash -c "echo this is a test" and if this returns vulnerable and this is a test it means that your OSX/Linux machine is affected. Remedy is to update to the latest version of bash.

1
  • 6
    Why as root? Completely unnecessary.
    – Mat
    Sep 27, 2014 at 13:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .