[dsr_]

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.

[kag]

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

[kragen]

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

[cbd1984]

So it isn't a bug if it's documented?

Seems like an interesting way to avoid paying out.

[serf]

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.