How can I ensure my Bash installation is not vulnerable to the ShellShock bug anymore after the updates?
-
See [Is there a short command to test if my server is secure against the shellshock bash bug?](http://security.stackexchange.com/q/68168) – Martin Schröder Sep 27 '14 at 17:40
-
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 07:44
6 Answers
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.
![](../../users/profiles/178049.webp)
- 2,595
- 2
- 18
- 32
-
1Can 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 (http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html). 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: http://seclists.org/fulldisclosure/2014/Oct/9 – billyw Oct 02 '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 05:40
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.
![](../../users/profiles/45673.webp)
- 5,693
- 3
- 24
- 49
-
5In addition to CVE-2014-6271, the incomplete fix from Red Hat in particular has its own that is also worth following: [CVE-2014-7169](https://access.redhat.com/security/cve/CVE-2014-7169). – DocMax Sep 25 '14 at 19:28
-
3One-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 07:15
-
1There's some Ubuntu specific details here http://askubuntu.com/questions/528101/what-is-the-cve-2014-6271-bash-vulnerability-and-how-do-i-fix-it - personally I had to upgrade from Ubuntu 13.10 to 14.04 to fix the issue – dodgy_coder Sep 26 '14 at 11:32
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 :'(
![](../../users/profiles/245368.webp)
- 121
- 3
-
-
-
-
Yep, sorry, I took it down. It was being exploited in ways I didn't like. – Liam Marshall Oct 02 '14 at 05:24
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
![](../../users/profiles/131574.webp)
- 831
- 5
- 24
- 39
You can submit your CGI URL to this online test:
![](../../users/profiles/245089.webp)
- 47
- 1
-
4
-
4
-
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 07:52
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.
![](../../users/profiles/245461.webp)
- 11
- 1