CVE-2014-6271

[Sitwon]

Fucking bash...

http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execution_through_bash

Comparisons to Heartbleed would not be misplaced.

[cooper]

One-liner to test if your system is vulnerable to this issue.

rm -f echo && env -i  X='() { (a)=>\' bash -c 'echo date'; cat echo

Note that you should probably do this in a newly created folder to ensure the 'echo' file you remove isn't a file you actually use.

If after running this the last line shown on the screen is the current date, you're vulnerable.

It would appear that the best fix at this point is to install the 'dash' shell and set it as your system default (what /bin/sh links to).

Make sure your scripts are written with '#!/bin/sh' as its first line rather than '#!/bin/bash'

Edited September 25, 2014 by Cooper

[cooper]

This bug can be exploited by pretty much anything that uses bash (and if /bin/sh is a symlink to bash, the C system() call will invoke just that) and provides it with a few environment variables. Some examples:

dhclient (runs as root and uses a number of fields directly from the DHCP ACK to populate the environment)

apache, when invoking any sort of script via an external invocation. So maybe (MAYBE!) fastcgi and php are in the clear, but TEST FIRST!

ssh in the sense that if you login to the remote system with a crafted command, the remote system will execute the malicious bit. (http://seclists.org/oss-sec/2014/q3/651 This means that if/once someone can alias your ssh command, they can use your succesful login to a remote host to make the remote host do their bidding using your account)

Edited September 25, 2014 by Cooper

[Sitwon]

I think this test a slightly more straight-forward:

env x="() { :;}; echo vulnerable" bash -c ":"

If it prints "vulnerable" to the screen, you are vulnerable. Test also with other shells on your system such as ash or zsh, sh is usually a symlink to bash.

':' is the no-op command in Bourne Shell. It's equivalent to 'true', but three characters shorter.

[cooper]

The patch that is available now fixes bash such that your test will not print 'vulnerable' but my test will still print the date, indicating that the patch was inadequate.

[Sitwon]

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

[ZaraByte]

http://www.exploit-db.com/exploits/34777/ for Metsploit Google Dork is: inurl:cgi-bin i've came across 15 sites so far in my area that are vulnerable 3 local radio stations 2 local news stations few goverment sites for my state.

[cooper]

Did you bother to inform them of this and if so, how did you go about doing this?

From what I understand, informing institutions in the US about vulnerabilities can get you sued. (Actually, the general concensus in Europe is that pretty much anything in the US can and will get you sued, but I disgress)

[ZaraByte]

I don't waste my time informing anyone about any problem they don't pay me for my time.

[cooper]

Fair enough.

[cooper]

https://github.com/hannob/bashcheck

That page details the current state of affairs. Particularly the last one on the page, linking to http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unofficial-patch-now.html is interesting as it's about the latest problem found which has not yet been officially announced, but the fix is being rolled out currently. I can only speak for my own systems, so Gentoo has it already.

The one-liner to test for the latest one is this:

foo='() { echo not patched; }' bash -c foo

Safe response: bash: foo: command not found

Unsafe response: not patched

[ZaraByte]

or https://bashbleed.org/

Edited September 29, 2014 by ZaraByte