Re: Nasty hole in postifx/procmail/cyrus

[guenther () GAC EDU (Philip Guenther)]

Dylan Griffiths <Dylan_G () BIGFOOT COM> writes:
> 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).
...
> qmgr sanitizes the variables.  Also, in testing I wasn't able to get shell
> code to execute.  .. and /s are a different matter.

Except, as pointed out by Wietse, you aren't using local, but rather
pipe and the filtering is done by local, not qmgr.  But that wasn't my
question.  I was wondering why you felt that passing the values via
variable assignments on the command line was better than passing them
via $1 and $2.

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

This is UN*X installation we're talking about, so let's consider the
restraints that this fact imposes.  I have yet to see a un*x system
which had a user whose login name contained a '/'.  Do _you_ have one?

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

procmail would be _reading_ the file as cyrus, so it's a matter of
what's readable by that user.

> A way to avoid this would be to have procmail check for forbidden
> characters in the username and extension.

The problem is that this procmail is being used in its generic
mailfilter mode, instead of its delivery mode.  As a result, it has no
basis on which to apply the semantics of "username" to the data in $1 or
the USER variable.  It's all just data.  Procmail's delivery mode knows
that the arguments on the command line are usernames to which the
message is to be delivered and will apply the requisite checks.
Unfortunately, procmail's delivery mode doesn't have a hook for
selecting default delivery via a program, thus the fallback to using
procmail's more generic mailfilter mode.  Having given up those checks
in procmail the administrator has to take them upon himself or herself.
The author of the rcfile dicussed here failed to do so.

(If anyone is interested in implementing such a hook in procmail they
should send me email.)

Philip Guenther