This seems to be a vulnerability that affects:

1) CGI scripts written in Bash (why?) that accept sanitised inputs

2) Some, non-default, configurations of OpenSSH with Bash

Amazon AWS may have released their fix to their Linux AMI's. All my Amazon servers had over 200 updates to apply this morning.

The issue is that CGI scripts convert http request headers into environment variables, and how Bash treats some of these environment variables to execute code.

CVE-2014-6271 [web.nvd.nist.gov]

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code 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.

Based on some of the reports I have read Report 1 [isc.sans.edu], Report 2 [access.redhat.com] is that the current patches are incomplete.

Please stay tuned.

I'm hearing that, too, and some exploits have already been discovered. The best bet is to update with an incomplete patch for the time being.

I just installed bash updates, and I'll install more when the come along.

This may explain all the crazy URLs we see in our log files as people are trying to create attack vectors using URLs that don't seem to make any sense.

FWIW, I've tried to force things to bail at the highest level when I detect them but if Apache can even cause the problem, them I'm out of ideas short of starting to write filters in the router itself to keep them from even getting to the computer.

That seems the only way to really stop certain types of attack vectors is to filter the URLs at the router and only let normal looking URLs pass and block anything out of the ordinary.

Sigh.

They can do this attack via the user agent string.

I won't post an example because it's trivially easy.

The header agent can be used to track in this case

@inrediBill, as far as I can tell you only have a problem with Apache IF you pipe log output in a way that passes it through the shell. Check your Apache config:

[httpd.apache.org...]
[httpd.apache.org...]

Next, check CGI scripts - if you have any. CGI scripts written in, or calling, BASH are vulnerable.

The next problem are malicious DHCP servers. This is not going to be a common vector

That leaves worries about breaking out of restricted ssh shells and CUPS.

As long as it's patched NOW then things should be ok. Problem areas, though, are likely to be things like industrial control systems and embedded systems (eg some routers).

I found the following test on http:[//]www[.]zdnet[.]com/shellshock-how-to-protect-your-unix-linux-and-mac-servers-7000034072/#ftag=RSS86a1aa4 (worth reading)

-----
...run the following command from a Bash shell:

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

If you get the result:
vulnerable this is a test

Bad news, your version of Bash can be hacked.

If you see:
bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

You're good. Well, to be more exact, you're as protected as you can be at the moment.
-----

It's possible that another bash bug may be found - or something in a similarly vulnerable situation. The thing about linux, though, is that bugs are fixed in very short times and patches/fixes are available as soon as the fixes have been tested. Unlike Windows (up to at least a month) or Mac (when we get around to it -as of this posting, Apple say there will be no immediate fix for shellshock). The linux problem is people: those who do NOT patch ASAP. Or who cannot.

The most likely infection path is through web sites hosted on linux (or Mac) servers that have not been patched (for which there is no real excuse!). Apart from trying to pass on the bash infection, I would guess that the biggest risk is to Windows users who hit an infected site. However, Windows users are ALWAYS vulnerable unless they know what they are doing, so nothing new there, then.

Patch was easy and I'm still just using the simple tests posted around

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

Reports A-OK... so hopefully I'm good for now.

Ubuntu released the patch to repos at least 14 hours ago, so the three largest distros are OK, as are those based on them to the point of sharing repos.

I think there is a deeper lesson though: shells were never meant to be tough enough to be exposed like this: you should not pass unsanitised input to a shell anymore than you would to a database. I think some developers had already realised this, which is why | pipe behaviour for log output changed between Apache 2.2 and 2.4.

Apple say there will be no immediate fix for shellshock

That should make anyone running servers on MacOS think again.

And a "final" patch today which claims to fix all known bugs. Info plus test code at...

http:[//]www[.]zdnet[.]com/shellshock-better-bash-patches-now-available-7000034115/#ftag=RSS86a1aa4

The point about Mac, according to Apple, seems to be that if you don't meddle with unix (which most "personal" users don't) then it's ok. Which completely ignores apple servers...

No one has mentioned Apache on Windows - I assume it uses some kind of bash?

And aren't many phones linux-based? Again no information.

My Ubuntu Desktop (Debian based) had a Bash and kernel patch applied late last night (eastern US time). Now: Bash 4.3-7 with 3.13.0-37 kernel.

@dstiles

This became long and needs a TL;DR version:

You are probably safe on any OS that does not default to bash for running shell scripts: so any of Windows, Debian, Ubuntu, FreeBSD, NetBSD, Android are safe, as are many others.

As far as I can tell Apache only uses the shell (not necessarily bash) to pipe the log, and then not always. On Windows it probably uses whatever Windows provides, on Ubuntu and recent versions of Debian it will use dash instead of bash. A quick fix on other OSes is to install dash and symlink /bin/sh to dash (although that may break other things!).

Apache 2.0 always uses the shell to spawn, so if you have something like (example from the Apache docs) in your config you have a problem

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common 

Apache 2.2 you can spawn without using a shell by replacing | with ||

Apache 2.4 is usually safe as both | and || spawn without using a shell, although you use a shell with |$ I think very few people will have done that.

Thanks. A lot of exploits have been generated, though, and at least one has been added to a "standard" malware driving kit.

Although I've made sure all of my machines have the latest bash versions and have checked them for exploitability I don't actually have any facing the internet in any way, just a few "locally" used tools.

Hoople: My version of bash (several machines with linux Mint Maya 13 based on ubuntu 12.04) returns:
GNU bash, version 4.2.25(1)-release (i686-pc-linux-gnu)

That is as of now (updated yesterday). Not sure why it differs from yours but I assume your ubuntu is later than mine. :)

Any light on how can this affect Perl Script based applications on server?

Does it use bash?

As long as the server has been fully updated (at least a daily task) then it should be ok, I would have thought.

thanks dstiles, it uses bash in 3 lines, I know got it clear how to avoid this, fixed.

There was another bash update today (Mint/Ubuntu).

And now an exploit (fixed) in rsyslog...