Commands can be:
portscan (scans a host for open ports)
tcpflood (try to keep 1000 TCP connections open to a host for a specified period of time);
udpflood (send UDP packets to all ports on a host with an payload of a specified number of 'A' characters for a specified period of time);
httpflood( send HTTP requests to a host for specified period of time [with HTTP Keep-Alive header]);
shell (execute arbitrary commands on the host);
google (use google to find other hosts to infect [targets modules.php]);
version (returns bot version)
All commands send status back via IRC.
There are several brazilian portuguese strings and comments, although is not clear if the author is brazilian.
This requires a webserver to be running CGI (mod_cgi or whatever) and the get request has to go to a valid page, correct? So in this case `GET /cgi-bin/hello ... yada yada yada` /cgi-bin/hello has to be a valid location.
So, explain to me how this is any worse than any remote execution vulnerability in something like PHP?
Environment variables are passed around all the time.
Why does it need to be worse than something you might find in PHP? If it's a worm that's been found in the wild spreading by exploiting a remote execution vulnerability in bash and cgi, isn't that bad enough?
Because that's what it's being hyped as, or more correctly hyped as "OH MY GOD IT'S THE END OF EVERYTHING" when in reality it appears that if you're not running ssh with forcecommands or a webserver with CGI enabled, you don't care, just like if you didn't run a webserver with PHP enabled a PHP vulnerability wouldn't really be much of an issue to you.
But it needs something to expose bash to the outside world. Without mod_cgi (or the like) or sshd with a specific configuration, a vulnerable bash isn't going to be remotely exploitable.
sendmail = popen(sendmail_cmd, "w");
1. /bin/sh is bash
2. PHP has set environment variables with user-provided data
#1 is often the case, but is much less common now than in the past.
#2 is not commonly the case, PHP does not even automatically create PHP variables from user-provided data anymore (because it is a terrible idea to put untrusted data into a trusted scope without sanitizing).
> sendmail = popen(sendmail_cmd, "w");
> Which calls /bin/sh to execute sendmail_cmd.
Are you sure? It looks like (at least by default) sendmail_cmd is a string constructed by putting sendmail_path (from php.ini) together with the various options passed to mail(). For most *NIX sendmail_path is going to be /usr/sbin/sendmail and so would execute /usr/sbin/sendmail -t -i email@example.com 'message string'
popen()'s man page says:
FILE *popen(const char *command, const char *type);
The command argument is a pointer to a null-terminated
string containing a shell command line. This command is
passed to /bin/sh using the -c flag
Ideally there would be something like a popenve() to simplify the process of opening the pipe(s) and passing arguments and environment.
There are also various other variations on the popen() concept, like my own popen3() implementations in C (note that I'm not the only person to write a popen3; Python, Ruby, and probably other languages have their own).
However, I mimicked the real popen(), and my implementation uses /bin/sh as well. It would be easy to make a version of popen3() that accepts argument and environment arrays, but it would still be insecure if the environment was set to the calling process's environ pointer, and/or the command to be executed was a /bin/bash script.
And it is safe, POSIX sh does not support exported functions, that is a bash-ism.
From what I can tell you are affected only if you use CGI or the like somewhere in your response chain. AFAIK most people use http reverse proxies, phpfm, wsgi and the like. They are all unaffected.
So CUPS printer servers at universities may be vulnerable. Dhclient may be vulnerable to malicious DHCP responses. Anything that calls out may be vulnerable (lots of mail libraries actually call /usr/bin/sendmail or the like; better hope they don't use system() or a bash /bin/sh to do it).
This is a big deal because there's a ton of stuff that uses environment variables that is and is not a web server, and very little time to track it all down before a black hat or oppressive regime gets there first.
What I don't understand is why everybody seems to think its necessary to start posting every script kiddies attempt at spreading their crappy ddos / botnet scripts via the vulnerability.
Are you running sshd with ForceCommand? - Get Patching (when a patch is out)
Are you running a webserver that uses 'old style' CGI (are you really sure you're not?) - Get Patching (when a patch is out)
Are you absolutely sure neither of the above is true? Then patch bash in your next patch cycle.
The super-hype vulnerabilities are getting is just muddying the waters when trying to get actual information.
Hypothetical: some GPG library is just a wrapper around /usr/bin/gpg. Maybe that library uses an environment variable to set a password that doesn't show up in ps. Maybe that library used system() instead of execve(). That password is now an attack vector.
See also /usr/bin/mail called by mail() functions in scripting languages, /bin/hostname, /bin/uname, etc. If any user-controlled variable is set in the environment, those calls become potential attack vectors
That's why mod_cgi or sshd (in one configuration) make this bad, they execute whatever command passed by design. To do that with most everything else, you would need a remote exploit in that program, making the bash exploit somewhat moot in that case. Or you're not sanitizing your inputs in which case you have another problem anyway.
Bash, on it's own, is not remotely callable.
How about all those torrent clients? Do they safely shell out when doing transcoding stuff? I don't know - do you?
How about the absurd rube goldberg contraption that is modern email processing?
How about all of those scripts that crawl various web pages? Do they shell out anything, or set environment variables? Not just the ones you wrote, but any of the ones that are potentially being used within your organization? (it just takes one owned box in the network to gain a foothold)
Sanitization is an orthogonal issue; no amount of escapeshellarg() would save someone from this issue, especially if the call to Bash is several layers of library calls and program executions removed from the developer's code (see pyre's comment: https://news.ycombinator.com/item?id=8368861).
 With the caveat that it's possible to limit the inherited environment variables, but this is rarely done, and even things like $PATH could be potential vectors depending on the code.
# type foo
foo is a shell function
# export -f foo
-sh: export: Illegal option -f