[10117] in bugtraq
Re: More procmail
daemon@ATHENA.MIT.EDU (Philip Guenther)
Tue Apr 6 22:13:57 1999
Date: Tue, 6 Apr 1999 20:00:03 -0500
Reply-To: Philip Guenther <guenther@GAC.EDU>
From: Philip Guenther <guenther@GAC.EDU>
X-To: Chris Evans <chris@FERRET.LMH.OX.AC.UK>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Mon, 05 Apr 1999 19:40:37 BST."
<Pine.LNX.3.96.990405193505.29900A-100000@ferret.lmh.ox.ac.uk>
Chris Evans <chris@FERRET.LMH.OX.AC.UK> writes:
...
>As a summary local users can dump the contents of any file to screen. As a
>comment I would suggest anyone running procmail with elevated privs either
>
>a) Needs their head examined or
>b) Hasn't read the code.
>
>Here is a quote of a previous mail I sent various people when I first
>found the file handling issue. I also recommended to the procmail team
>that they review _all_ of their file handling code. I have no idea whether
>this recommendation was taken on board or not..
Hmm, I guess I failed to cc you on the discussion that later took place
on this issue. What we eventually settled on and was incorporated into
version 3.12 was for procmail to always open user rcfiles as the user
(/etc/procmailrc will still be opened and processed as root). On some
systems where special group privileges are needed to deliver to the
mailspool but that have broken set*gid() system calls, procmail will
attempt the open as root and if it succeeds then it'll close it, become
the user, and open it again. This last case may still allow for DOS
attacks by symlinking to, say, a serial device that blocks on open, so
I suppose the open as root should be a non-blocking open. The truly
paranoid will abolish the central mailspool directory and group 'mail'
in favor of spooling mail to the user's home directory, a setup
procmail readily supports.
As for the rest of the file handling code, what I've had the time to
review has looked safe. Procmail becomes the user before it starts
processing the contents of the $HOME/.procmailrc, so problems should be
limited to what the user could have done without procmail at all.
While the permissions of the $HOME/.procmailrc are checked closely,
procmail tries to the trust the user the rest of the time; if the user
wants to process recipes from someone else's rcfile, procmail will let
them: trusting the other user was their explicit choice. Resource
consumption attacks (say, opening /dev/zero as an rcfile) should be
dealt with like all resource consumptions attacks: audit and keep a
baseball bat next to your desk.
Philip Guenther
Procmail Maintainer
bug@procmail.org
