So, the Shellshock vulnerability...
Yes, this one really is the biggest vulnerability to hit UNIX-like systems in decades.
Yes, it is in the wild now, and yes, it IS a major problem.
So yeah... you really do have to pay attention to this one.
Briefly, many UNIX-like systems, including most Linux systems, Mac OSX, and many others, use, or at least have installed on them, a variant of a program called "bash' (the "Bourne Again SHell").
To say that it's one of the most widely used pieces of software in the world would be a dramatic understatement.
Recently, it has been discovered that most bash variants (and by the way, there are hundreds of them, if not thousands, extending back to 1989), when invoked with certain variables, can be forced to execute malicious code.
There are already patches available for many systems which will either fix or mitigate the problem, but there are literally millions of systems out there, and it will take a lot of time and effort to fix them.
There are also many systems which either can't be fixed for some reason or another, or whose owners don't even know that there is a problem.
These days, just about every piece of computing hardware out there that isn't an actual Windows server or PC, runs a UNIX-like OS; and many of those have some variant of the software in question installed on them by default. Even if it's not actively used on the system, many systems have it installed by default, and few bother to remove it.
Even if you don't run any UNIX-like boxes, your vendors, your partners, your bank, your power company, your... everything... runs them.
...Hell, your TV or stereo might be running linux these days, and your router probably is.
Do YOU know what operating system is running on every single piece of computing hardware in YOUR company? In every embedded system? In your printers, your photocopiers?
Also, because this vulnerability extends back so far, it's entirely possible... actually it's a damn near certainty... that the code containing the vulnerability in question has been reused in other software (including other shells not considered bash variants, and other entirely unrelated software); which may now also be vulnerable.
So, the gory details...
https://www.us-cert.gov/ncas/alerts/TA14-268A
Read the CERT link, then read this:
http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/
And this;
http://arstechnica.com/security/2014/09/concern-over-bash-vulnerability-grows-as-exploit-reported-in-the-wild/
And if you want some technical depth, this:
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
I don't have much else to add about the vulnerability itself... but I do want to talk about a common problem with how people think of and respond to issues like this.
Confusing Vectors with Vulnerabilities.
I'm noticing a lot of folks out there seem to think that because they're not running a web server, or that they're not providing services to the internet, that they're not impacted by this vulnerability.
That is absolutely not the case.
It's very important to understand, the attack vector for this vulnerability is not JUST web services; that's just the most common and simplest way to exploit it remotely, and the first exploit seen.
This should be obvious, but any service that may pass unvalidated (or poorly validated) remote input to any external shell or command parser, is a potential point of compromise.
There are any number of common services that may do this, including DHCP and autoproxy config, various SSH configurations, various VPN services, some remote management or configuration services, GIT and other code and content management systems, various file sharing and syncing services, various media services, various backup and archive services...
Also remember the vulnerability applies to local command execution and local services as well, not just remote. This is a vulnerability in a core component of the operating environment, not just in any particular service.
Unlike most other operating systems, where an application or service might perform an external function for itself, or through a system API; because of UNIX-like systems fundamental architecture and long standing convention, almost any process might invoke and pass input to an external command parser or shell for almost any reason. When they do, it's usually the default shell for the system, or for the UID the process runs under, and often that default is bash.
Even if bash is not the default for a system or user, some processes may invoke bash explicitly, to avoid potential environment, syntax, or parsing errors (or simply because that's what the programmer was comfortable with).
Also, even if a process explicitly invokes a command parser or shell other than bash, it is common to find that bash has been aliased or linked to the command for the other shell. In many environments, running the command "sh" will in fact invoke a bash shell.
Finally, as I noted above, bash is so ubiquitous, and the code for it has been around so long; it's entirely likely that other shells and command parsers (and possibly other types of software as well) share this same vulnerability.
Again, these should be obvious, but it's surprising how easily we allow ourselves to overlook or forget the basics.
Don't assume you're safe just because you're not running a web server on the machine, or because the machine isn't providing services to the internet, or because you're " not using bash".
Address the vulnerability, not JUST the vector.