This lines in my maildroprc which cause this to happen are: --- import SENDER import RECIPIENT import HOME if ($SENDER ne "") { FROM=$SENDER } else { FROM="[EMAIL PROTECTED]" } if ($RECIPIENT ne "") { TO=$RECIPIENT } else { TO="[EMAIL PROTECTED]" } xfilter "/opt/amavis/sbin/amavis $FROM $TO" ---
The message itself is probably just a piece of spam, but the following is remarkable:
1. Courier accepts the email address containing an | sign in the From field.
Correct. There's nothing wrong with a | character in an E-mail address.
2. Courier tries to pass it to the anti-virus check script (as specified in maildroprc).
Wrong. Courier doesn't pass anything. A custom-written script does all the passing here.
3. Bash interprets this as a pipe and is thus executing a commmand specified in the 'From' field.
I can very well imagine this could lead to a dangerous exploit if it were
Correct. Which means that if you're going to write a mail filtering recipe that passes externally-supplied data, then you better damn make sure that you're passing the external date safely.
specially crafted for this purpose. Besides, I believe the RFC's do not allow the | sign in e-mail addresses... So why is courier allowing this?
Courier is not allowing anything. This script allows this gaping security hole in this script.
This of course wouldn't have happened if I hadn't left such a large hole in my maildroprc, although I just followed the amavis documentation.
Well, then, amavis' documentation needs to be updated.
man maildropfilter, and read what it says about the "escape" function.
But I am still very curious to know why courier decides to allow this..
Because there's no valid reason to disallow this.
pgp00000.pgp
Description: PGP signature
