5245864 2000-07-02 20:03 /97 rader/ Postmaster
Mottagare: Bugtraq (import) <11548>
Ärende: Re: Nasty hole in postifx/procmail/cyrus
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <395DA418.5314B33C@bigfoot.com>
Date: Sat, 1 Jul 2000 01:56:08 -0600
Reply-To: Dylan Griffiths <Dylan_G@BIGFOOT.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Dylan Griffiths <Dylan_G@BIGFOOT.COM>
X-To: postfix-users@cloud9.net
To: BUGTRAQ@SECURITYFOCUS.COM
John Pettitt wrote:
>
> There are a number of hacks about that allow postfix to deliver to cyrus
> imap mailboxes via procmail. It turns out that at least one of these has
> a hole in it that allows bad guy to run code as the cyrus user.
>
Secure Postfix+Procmail+Cyrus micro-howto
This is should be secure, as $1, $2, etc, are not trusted nor read.
Postfix parses the user@domain.dom part for us, and feeds USER= and
EXTENSION= lines to procmail, which works on those variables only
The entry in master.cf for procmail to be used as a mailbox_transport:
procmail unix - n n - - pipe
flags=R user=cyrus argv=/usr/bin/procmail -p /home/cyrus/procmail.common
\
USER=${user} EXTENSION=${extension}
The procmail.common file:
#################################################
# procmailrc
# you must explicitly set a path if you're gong to be spawing programs
PATH=/usr/cyrus/bin:/bin:/usr/bin:/usr/local/bin
SHELL=/bin/bash
LOGFILE=/home/cyrus/$USER.log
DELIVERMAIL=/usr/cyrus/bin/deliver
###############################
# If users want to be able to define their own private recipes
# and put them in their home .procmailrc files, comment out
# the next definition.
#
# These recipes will be processed BEFORE the user-specific
# recipes that are kept in the /home/cyrus directory
#
#INCLUDERC=/home/$USER/.procmailrc
#
# If you do NOT want to define any user-specific recipes
# that you manage centrally (perhaps because you only want
# to allow your users to "roll their own," then
# comment out the following line. Otherwise, you have
# to create a file for each user in the form:
# procmail.username -- for example, procmail.Joe
INCLUDERC=/home/cyrus/procmail.$USER
#
EXITCODE=
# If this fails, it tries without the extension
:0w
| $DELIVERMAIL -a $USER -e -q -m $EXTENSION $USER
# If this fails, it returns error!
:0w
| $DELIVERMAIL -a $USER -e -q $USER
:0 e
{
EXITCODE=$?
HOST
}
An example procmail.user file:
:0
* ^Return-Path: +<owner-postfix-users@postfix.org
{ EXTENSION="postfix" }
:0
* ^TOBUGTRAQ@SECURITYFOCUS.COM
{ EXTENSION="bugtraq" }
HTH.
--
www.kuro5hin.org -- technology and culture, from the trenches.
(5245864) ------------------------------------------(Ombruten)
5245911 2000-07-02 20:57 /80 rader/ Postmaster
Mottagare: Bugtraq (import) <11553>
Ärende: Nasty hole in postifx/procmail/cyrus
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: jpp@gatekeeper.cloudview.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <4.3.2.7.2.20000629232105.00b00ae0@gatekeeper.cloudview.com>
Date: Fri, 30 Jun 2000 15:12:36 -0700
Reply-To: John Pettitt <jpp@CLOUDVIEW.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: John Pettitt <jpp@CLOUDVIEW.COM>
X-To: postfix-users@cloud9.net
To: BUGTRAQ@SECURITYFOCUS.COM
There are a number of hacks about that allow postfix to deliver to cyrus
imap mailboxes via procmail. It turns out that at least one of these has
a hole in it that allows bad guy to run code as the cyrus user.
Prerequisites:
1) procmail installead as mailbox_transport under postfix (this is a
hack to get procmail to run under the cyrus user id). If procmail is
run as mailbox_command there does not seem to be an issue and postfix
nukes all the shell stuff before procmail gets called.
2) an /etc/procmailrc that looks like this (or similar - the main
feature being to trust the userdata - in this case $1)
# some reasonable defaults
SHELL=/bin/sh
DELIVER="/usr/cyrus/bin/deliver -a $1"
MAILTO=$1
MAILBOX=$2
# this enables automated procmail recipe creation for users;
# roll your own tool to allow creation of procmail recipes on a per-user
# basis and place them there, but don't let users edit their own recipes
INCLUDERC=/etc/procmailrcs/$1
# make sure EXITCODE is clear: then it will take the value of the TRAP return
EXITCODE=""
TRAP="/usr/cyrus/bin/deliver -m $2 -- $1"
# Procmail voodoo. The TRAP handles the mail delivery. We have to
# prevent procmail from attempting a second delivery.
#
# in one line, kill procmail:
HOST=
When procmail processes the INCLUDERC and TRAP lines backquote
expansion happens. Sending a message `shell commands`@myhost.com
will cause the commands to run under whatever ID procmail happens to
be running as (typically cyrus).
Also if mail is sent to baduser procmail will disclose the path to it's
include dir in the reply. Mail can then be set to say ../passwd which
will case procmail to read passwd as a recipie file and barf it's contests
as an error response.
All of the above can be plugged by adding:
:0
*$ ! $MAILTO ?? .*[A-ZA-z0-9\-_]?
/tmp/bad
#or /dev/null according to taste
before the INCLUDERC line in /etc/procmailrc
John
John Pettitt Email: jpp@cloudview.com
Remember: It's Always Darkest just Before it goes Pitch Black.
Notice: If you want your email to be private you should encrypt it!
My PGP keys are on the MIT & pgp.com servers.
PGP Key fingerprint: 81B5 446D 3E0E 1CDE 5A45 644A A744 54C4 7886 3658
You can get PGP free from http://web.mit.edu/network/pgp.html
(5245911) ------------------------------------------(Ombruten)
5255356 2000-07-06 00:09 /79 rader/ Postmaster
Mottagare: Bugtraq (import) <11588>
Ärende: Re: Nasty hole in postifx/procmail/cyrus
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200007030040.TAA07811@solen.gac.edu>
Date: Sun, 2 Jul 2000 19:41:49 -0500
Reply-To: Philip Guenther <guenther@GAC.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Philip Guenther <guenther@GAC.EDU>
X-To: John Pettitt <jpp@CLOUDVIEW.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <4.3.2.7.2.20000629232105.00b00ae0@gatekeeper.cloudview.com>
John Pettitt <jpp@CLOUDVIEW.COM> writes:
>There are a number of hacks about that allow postfix to deliver to cyrus
>imap mailboxes via procmail. It turns out that at least one of these has
>a hole in it that allows bad guy to run code as the cyrus user.
...
># this enables automated procmail recipe creation for users;
># roll your own tool to allow creation of procmail recipes on a per-user
># basis and place them there, but don't let users edit their own recipes
>INCLUDERC=/etc/procmailrcs/$1
>
># make sure EXITCODE is clear: then it will take the value of the TRAP return
>EXITCODE=""
>
>TRAP="/usr/cyrus/bin/deliver -m $2 -- $1"
...
>When procmail processes the INCLUDERC and TRAP lines backquote expansion
>happens. Sending a message `shell commands`@myhost.com will cause the
>commands to run under whatever ID procmail happens to be running as
>(typically cyrus).
The backquote expansion takes place when TRAP is re-expanded for
processing (the Bourne shell's "trap" command suffers the same
defect). The INCLUDERC assignment is safe from them. The correct
assignment to TRAP would delay variable expansion till TRAP is
expanded, and double-quote the user supplied variable even then to
prevent filename globbing and word breaking on spaces:
TRAP = '/usr/cyrus/bin/deliver -m "$2" -- "$1"'
(At least the original author got the "--" correct...)
>Also if mail is sent to baduser procmail will disclose the path to it's
>include dir in the reply. Mail can then be set to say ../passwd which
>will case procmail to read passwd as a recipie file and barf it's contests
>as an error response.
>
>All of the above can be plugged by adding:
>
>:0
>*$ ! $MAILTO ?? .*[A-ZA-z0-9\-_]?
>/tmp/bad
>#or /dev/null according to taste
>
>before the INCLUDERC line in /etc/procmailrc
Heh, you just opened a new hole: the syntax to match the regexp
against a variable's value doesn't put a '$' before the variable
name. The above will expand the value of MAILTO and then parse it as
a condition, allowing evil things if MAILTO starts with "?". Hmm,
your regexp is also broken: it will _always_ match, so the condition
will _never_ match.
The correct recipe would run something like:
:0
* MAILTO ?? [^-a-z0-9_]
{
# MAILTO contains a character that is neither alphanumeric,
# nor an underbar, nor a minus sign. We have no such users.
EXITCODE = 67 # EX_NOUSER
HOST
}
That should go somewhere above the INCLUDERC assignment.
Philip Guenther
(5255356) ------------------------------------------(Ombruten)
5255440 2000-07-06 00:44 /37 rader/ Postmaster
Mottagare: Bugtraq (import) <11590>
Ärende: Re: Nasty hole in postifx/procmail/cyrus
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <396272D6.AD805F8@bigfoot.com>
Date: Tue, 4 Jul 2000 17:27:18 -0600
Reply-To: Dylan Griffiths <Dylan_G@BIGFOOT.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Dylan Griffiths <Dylan_G@BIGFOOT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
> >procmail unix - n n - - pipe
> > flags=R user=cyrus argv=/usr/bin/procmail -p \
> > /home/cyrus/procmail.common \
> > USER=${user} EXTENSION=${extension}
>
>In my opinion, the bug is for procmail to execute commands in
>per-recipient files when running with someone elses privileges.
>
>The pipe transport DOES NOT filter $name expansions, because the
>command is not executed by a shell. This is described in the pipe(8)
>manual page.
>
>The local delivery agent DOES filter $name expansions, because the
>command is often executed by a shell. The filter is under control
>by the $command_expansion_filter configuration parameter. This is
>described in the local(8) manual page. This applies to any external
>command executed by the local delivery agent, including mailbox_command.
>
> Wietse
So postfix does support the neccesary filtering required to sanitize
the variables passed to procmail. If Postfix is properly setup,
Procmail would not be vulnerable to the originally described hole.
(5255440) ------------------------------------------(Ombruten)
5255462 2000-07-06 01:20 /79 rader/ Postmaster
Mottagare: Bugtraq (import) <11593>
Ärende: Re: Nasty hole in postifx/procmail/cyrus
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200007030102.UAA08437@solen.gac.edu>
Date: Sun, 2 Jul 2000 20:04:04 -0500
Reply-To: Philip Guenther <guenther@GAC.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Philip Guenther <guenther@GAC.EDU>
X-To: Dylan Griffiths <Dylan_G@BIGFOOT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <395DA418.5314B33C@bigfoot.com>
Dylan Griffiths <Dylan_G@BIGFOOT.COM> writes:
>Secure Postfix+Procmail+Cyrus micro-howto
>
>This is should be secure, as $1, $2, etc, are not trusted nor read. Postfix
>parses the user@domain.dom part for us, and feeds USER= and EXTENSION= lines
>to procmail, which works on those variables only
How is it more secure to pass the values as variable assignments on
the command line instead of as $1, $2, etc? The error is in how the
variables are used, not what they are named.
>The entry in master.cf for procmail to be used as a mailbox_transport:
>
>procmail unix - n n - - pipe
> flags=R user=cyrus argv=/usr/bin/procmail -p \
> /home/cyrus/procmail.common \
> USER=${user} EXTENSION=${extension}
Does postfix check $(user) and $(extension) for evil characters
(including whitespace) before passing them to procmail? Does it
require $(user) to be an actual username? If not the latter, you're
still open to the ../../etc/passwd hack, and if not the former then
your recipes still allow remote attackers to change the arguments
passed to deliver.
Procmail's variable expansion style was derived from the shells, and
therefore suffers all its defects. If you haven't sanitised it,
_must_ double-quote untrusted data to prevent filename globbing and
word breaking.
...
>INCLUDERC=/home/cyrus/procmail.$USER
Did you check USER for /s and ..s?
...
># If this fails, it tries without the extension
>:0w
>| $DELIVERMAIL -a $USER -e -q -m $EXTENSION $USER
What if EXTENSION or USER contains whitespace or a '*'? What if
EXTENSION is *empty* (Whoops, you just passed $USER to the -m flag.
I hope that didn't hurt).
# Only call deliver with an extension if we were passed a
# non-empty one
:0 w
* EXTENSION ?? .
| $DELIVERMAIL -a "$USER" -e -q -m "$EXTENSION" -- "$USER"
(Do you really want the -q flag here? You might as well turn off
quotas if you do.)
># If this fails, it returns error!
>:0w
>| $DELIVERMAIL -a $USER -e -q $USER
Likewise:
:0 w
| $DELIVERMAIL -a "$USER" -e -q -- "$USER"
Philip Guenther
(5255462) ------------------------------------------(Ombruten)