Bash Shell Vulnerability (shell shock)

Just a heads up: http://threatpost.com/major-bash-vulnerability-affects-linux-unix-mac-os-x
I just saw that this was already posted, although my link gives a diagnostic step that allows users to check their version of bash.

 

In https://access.redhat.com/articles/1200223 there's a test for vulnerability:

Code:

To test if your version of Bash is vulnerable to this issue, run the following command:

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

If the output of the above command looks as follows:

vulnerable
this is a test

you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

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

 

https://www.wilderssecurity.com/threads/major-bash-vulnerability-affects-linux-unix-mac-os-x.368559/

 

This is my output from the command:

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

But, to my understanding, the patch that was issued yesterday for bash is incomplete. In other words, it's not truly fixed yet. This is not good.

Later...

 

A new bash update just now. Hopefully that fixes it. Guess we'll soon find out.

Later...

 

On another website I found an alternative command to test if your version affected by the original vulnerability:

Code:

test="() { echo Hello; }; echo hacked" bash -c ""

If you get the output "hacked", you're affected.

In order to test if your version only got the incomplete first fix:

Code:

X='() { function a a>\' bash -c echo; [ -e echo ] && echo "hacked"

 

Here is a script that claims to test bash for all so far known vulnerabilities.

 

Bash bug: so, like, apply the unofficial patch now (CVE-2014-6277)

-- Tom

 

My results from tlu's link to bashcheck...

$ ./bashcheck
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

Later...

 

Hi Trespasser,

I got the same results after upgrading bash today from Wednesday's 1st update (4.2-2 ubuntu2.2) to yesterday's (4.2.2ubuntu2.5).

 

Yep, I got the same results for bash v. 4.3.026-1 under Arch Linux.

 

On a related note, has anyone taken a look at how many things in /usr/bin/, etc. are explicit bash scripts? On my Fedora/Xfce workstation I see 51 items...

 

I had 132 sh and bash related scripts in /usr/bin (not counting system links). I didn't take the time to open each script to see if they were explicitly bash.

Later...

 

The newest version of bashcheck checks against 6 public vulnerabilities. Result for Arch Linux:

Code:

Testing /usr/bin/bash ...
GNU bash, Version 4.3.27(1)-release (x86_64-unknown-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not explitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

 

OpenVPN Vulnerable To Shellshock Exploit.

-- Tom

 

Yes, indeed. You want to know that your VPN provider has been proactive.

 

Thanks, tlu.
My results...

$ ./bashcheck
Testing /bin/bash ...
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)

Variable function parser pre/suffixed [(), redhat], bugs not explitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

Later...

 

Improvement in v. 4.3.29 over 4.3.27:

Code:

Testing /usr/bin/bash ...
GNU bash, Version 4.3.29(1)-release (x86_64-unknown-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Not vulnerable to CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

 

FWIW, SELinux evangelist Dan Walsh writes that

Although I haven't looked into it, AppArmor should also offer some protection.

 

With the newest patches (patchlevel 053 for bash v. 4.2 and patchlevel 030 for bash v. 4.3) all known bash vulnerabilities are fixed. bashcheck reports:

Code:

Testing /usr/bin/bash ...
GNU bash, Version 4.3.30(1)-release (x86_64-unknown-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Not vulnerable to CVE-2014-6277 (lcamtuf bug #1)
Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)