Bash vulnerability

[bashiergui]

Can someone explain this to me please? it looks as if there are two versions of bash on the one machine.
I just dabble at the fringes of Terminal commands to see what’s happening on my headless Ubuntu box (dedicated to the Folding@home project). I use a Terminal on my Apple machines to do this checking.

You're not quite reading the output correctly.

bash --version

gives you

GNU bash, version  4.3.11(1)-release (x86_64-pc-linux-gnu)

which tells you that you have bash version 4.3 installed. It's not being specific with the details of the version beyond that.

apt-cache policy bash 
or  
dpkg -s bash | grep Version

gives you exactly the version you're using:

4.3-7ubuntu1.4 0

Looking here you see that the fixed versions of bash are 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, and 4.1-2ubuntu3.4.

[bashiergui]

My Bash still seems to be vulnerable to CVE-2014-6277. Even though I've installed the latest bash from Ubuntu. What am I missing?

You're right, but there are subtle details which make this less of a concern.

The CVE says "GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code or cause a denial of service (uninitialized memory access, and untrusted-pointer read and write operations) via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution."

Here are Canonical's notes on that CVE, which say "This issue is mitigated by Florian Weimer's prefix-suffix patch that is included in http://www.ubuntu.com/usn/usn-2362-1/ since bash parser vulnerabilities are now limited to specially named environment variables, and as such are no longer directly exposed to CGI scripts, SSH, etc. Once an upstream patch is made available, we will release bash updates, but we don't consider this to be a critical issue requiring immediate attention."

It's still a vulnerability, but they seem to be saying it's less critical because remote attackers can't directly exploit it. There is also a new confirmed bug report showing that CVE-2014-6277 is not completely mitigated yet.

[sammiev]

There is also a new confirmed bug report showing that CVE-2014-6277 is not completely mitigated yet.

Will be following this one for a little bit...

[daniel202]

Need some advice. Everything patched, everything is up to date but the following "test" fails. I can't exactly prove one way or another if the test is flawed or if I have missed something.

Advice appreciated.

env w='() { (a)=>\' sh -c "/bin/cat /etc/aliases"; echo ouch

This seems to work on any 12.04 patched machine, not sure if its a false positive or something else, am i just reading the command wrong?

[Penfold1971]

dpkg -s bash | grep Version[/CODE]gives you exactly the version you're using:

4.3-7ubuntu1.4 0

Looking here you see that the fixed versions of bash are 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, and 4.1-2ubuntu3.4.

Thanks for that explanation bashiergui.

[bashiergui]

env w='() { (a)=>\' sh -c "/bin/cat /etc/aliases"; echo ouch

This seems to work on any 12.04 patched machine, not sure if its a false positive or something else, am i just reading the command wrong?

Where did you find that test string?

[loyhz2ayj-jeff]

shellshocker.net/shellshock_test.sh

[daniel202]

Yes. its in the script mentioned. its also in some stupid video's people around the place have been watching.

shellshocker.net/shellshock_test.sh

Its meant to be CVE-2014-7169 (taviso bug) but the tests in https://github.com/hannob/bashcheck/...ster/bashcheck for example pass as does that script.

# Passes
CVE20147169=$((cd /tmp; rm -f /tmp/echo; env X='() { (a)=>\' bash -c "echo echo nonvuln" 2>/dev/null; [[ "$(cat echo 2> /dev/null)" == "nonvuln" ]] && echo "vulnerable" 2> /dev/null) | grep 'vulnerable' | wc -l)

# Fails
env w='() { (a)=>\' bash -c "/bin/cat /etc/aliases"; echo ouch

[bashiergui]

Not really sure what that test string was doing exactly. I tested it on ksh, dash, and bash. All three handled it the same way: they refused to execute the first part, then they all echoed "ouch".

I suspect this was fixed in one of the bash patches by changing the way bash handles environmental variables. Specifically bash now sets the environment across a privilege boundary like all the other shells. So a vulnerable shell would have allowed the string to set the environment. The patched version did not.

I can't get myself excited about this one. There will likely be many more patches for bash as the world keeps beating on it. Until then I wouldn't call this one critical.

[ecophobia]

It will take some time to completely solve this attack vector (not just CVE 2014-6271 & CVE 2014-7169 vulnerabilities). We should see a few more vulnerabilities to show up in the coming months. I am scared to think how many unpatched devices out there incl SCADA.