Jump to content

CVE-2014-6271


Sitwon
 Share

Recommended Posts

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 by Cooper
Link to comment
Share on other sites

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 by Cooper
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...