>> 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.
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...)
Why it's not exploitable without the shellshock-vulnerable bash, you could argue that qmail is not validating the input in accordance with the RFCs. In fact, that's one of the things I said here: http://marc.info/?l=qmail&m=141183309314366&w=2
Input validation is an orthogonal issue here, since bash doesn't know anything about RFC821/RFC2821, doesn't expect data in that format, and doesn't make any guarantees about what it will or won't do on such data.
The only reasonable policy for a shell to follow is to be entirely input-agnostic and never execute code based on the contents of an environment variable (regardless of which RFCs the contents conform to).
Of course bash doesn't know and shouldn't know about the SMTP RFCs. Yes, bash shouldn't execute code in variables. I was talking about input validation in qmail itself, not bash.
Even though bash shouldn't have executed the code, better input validation and RFC conformance in qmail could have prevented exploitation of bash. You know, defense-in-depth.
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.