79

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

  • Please note there are two other vulnerabilities in bash still unpatched (CVE-2014-7186 and CVE-2014-7187). – Deer Hunter Sep 27 '14 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. – BeowulfNode42 Sep 29 '14 at 7:44
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.

  • 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 '14 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. – BeowulfNode42 Sep 29 '14 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 '14 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 '14 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 '14 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.

  • 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 '14 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 '14 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 – dodgy_coder Sep 26 '14 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 :'(

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

You can submit your CGI URL to this online test:

http://shellshock.iecra.org

  • 4
    It is polite to provide reasons for downvotes. – David Sep 26 '14 at 1:14
  • 4
    "We log all scans"??? Creepy. I'd download the python and run it myself. – Brad Sep 26 '14 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 '14 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.

  • 6
    Why as root? Completely unnecessary. – Mat Sep 27 '14 at 13:58

protected by Rob Moir Sep 28 '14 at 17:14

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.