"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.
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.
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, ...).
This being a feature and not a bug is the far worse alternative, that means the badness is inherent.
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.
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.
