Shellshock Security Bug in Bash
[…] the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents.
[…]
Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the environment variable).
Imagine an HTTP request like this:
target = 0.0.0.0/0 port = 80 banners = true http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html) http-header = Cookie:() { :; }; ping -c 3 209.126.230.74 http-header = Host:() { :; }; ping -c 3 209.126.230.74 http-header = Referer:() { :; }; ping -c 3 209.126.230.74[…]
Put succinctly, Robert has just orchestrated a bunch of external machines to ping him simply by issuing a carefully crafted request over the web. What’s really worrying is that he has effectively caused these machines to issue an arbitrary command (albeit a rather benign ping) and that opens up a whole world of very serious possibilities.
[…]
The headlines state everything through 4.3 or in other words, about 25 years’ worth of Bash versions. Given everyone keeps comparing this to Heartbleed, consider that the impacted versions of OpenSSL spanned a mere two years which is a drop in the ocean compared to Shellshock.
Put another way, unless you have very old code running on your web servers, and unless you are doing something like running a public SSH server that allows restricted log-ins (e.g. to run Git or Subversion via SSH, but nothing else), the chances are that you aren’t vulnerable to remote exploits based on this. You should check, but you should not panic.
Future South Technologies (via Mike Rundle):
While watching their activities, I noticed something very odd. All of the hosts that appeared to be running their perl script were pretty high profile. Not just random web servers around the web, though they do have a separate channel for that. But this channel had a lot of domains sitting in it that would have most you your jaws dropped. The most prevalent of the two being lycos.com and – wait for it – yahoo.com.
The theory is the claim promoted by open-source advocates that “many eyes makes bugs shallow”, the theory that open-source will have fewer bugs (and fewer security problems) since anyone can look at the code.
What we’ve seen is that, in fact, very few people ever read code, even when it’s open-source.
Not only is nearly every version of Unix vulnerable, including Linux and OS X, but most of the initial patches are not completely effective at blocking the hole. It’s a near-worst-case scenario where we have a piece of software on nearly every non-Windows server on the Internet — and plenty of personal computers thanks to Apple’s market growth — that is vulnerable to multiple kinds of remote attacks, all capable of completely taking over the system, with no way to stop it completely.
Apple’s OS X bash Update 1.0:
This update fixes a security flaw in the bash UNIX shell.
