Re: Nasty hole in postifx/procmail/cyrus

[Dylan_G () BIGFOOT COM (Dylan Griffiths)]

Philip Guenther wrote:
> How is it more secure to pass the values as variable assignments on the
> command line instead of as $1, $2, etc?  The error is in how the
> variables are used, not what they are named.

We are using the internal ${USER} and ${EXTENSION} variables, as produced by
local (http://www.styx.org/postfix/local.8.html).

http://www.styx.org/postfix/delivering.html

Local receives the mail from qmgr.

"The queue manager is the heart of the Postfix mail system. It contacts the
local, smtp, or pipe delivery agents, and sends a delivery request with
queue file pathname information, the message sender address, the host to
deliver to if the destination is remote, and one or more message recipient
addresses. "

http://www.styx.org/postfix/qmgr.8.html

qmgr sanitizes the variables.  Also, in testing I wasn't able to get shell
code to execute.  .. and /s are a different matter.

> Does postfix check $(user) and $(extension) for evil characters
> (including whitespace) before passing them to procmail?  Does it require
> $(user) to be an actual username?  If not the latter, you're still open
> to the ../../etc/passwd hack, and if not the former then your recipes
> still allow remote attackers to change the arguments passed to deliver.

The username and extension will always be an argument to deliver.  How else
is deliver to know the recipient?  Postfix sanitizes the variables a bit
(see above), so the only problem would be if they have / and ...  Those are
perfectly valid characters according to the relevant RFCs (822).

Jul  4 04:59:47 xxxxxx procmail[1935]: Error while writing to
"/home/cyrus//etc/passwd.log"

I think the danger is small because on most systems, user cyrus only has
write access to a few controlled directories.  There may be a vulnerability
to the mail spool.  A way to avoid this would be to have procmail check for
forbidden characters in the username and extension.

(A side note: if your /etc/passwd reveals anything beyond a list of
usernames, you have a problem.  Good shadow password systems have existed
for some time now, and most of them use the relatively strong MD5 and
Blowfish, as opposed to simple DES.)

> Procmail's variable expansion style was derived from the shells, and
> therefore suffers all its defects.  If you haven't sanitised it, _must_
> double-quote untrusted data to prevent filename globbing and word
> breaking.

> > INCLUDERC=/home/cyrus/procmail.$USER
> Did you check USER for /s and ..s?

No.  I don't know enough procmail rc language to write something like that.
:-(

> What if EXTENSION or USER contains whitespace or a '*'?  What if
> EXTENSION is *empty*  (Whoops, you just passed $USER to the -m flag.  I
> hope that didn't hurt).

It shouldn't hurt, unless INBOX.$user exists.  In that case, the user will
simply have their mail show up there by default.  Procmail's language
doesn't seem to have a nice if(), else clause system.  This stopped me from
making a cleaner script.  That, and I didn't know how to check to see if a
variable was NULL or initialized to a value.

> (Do you really want the -q flag here?  You might as well turn off quotas
> if you do.)

That's just from my system.  I assume if you can setup Postfix + procmail +
Cyrus, that you know to check stuff posted to Bugtraq and use it as an
example (not cut & paste) ;-)

The previous procmail rc I used (before I did the 0w chaining of deliver
attempts) gave arguments and mail to a perl script which did the if/else
logic for the extension valid/invalid cases.  Given some time, I'm sure it
could be developed such that you would be able to have Postfix deliver to
the perl script, which did sanity checking, clause matching, and delivery.
It would likely be safer than procmail.

The best solution is to wait for the LMTP delivery agent to show up in
Postix, and use the Sieve language that is bundled with Cyrus.

--
    www.kuro5hin.org -- technology and culture, from the trenches.