Date:	Mon, 5 Apr 1999 02:23:59 -0500
From:	Philip Guenther <guenther@GAC.EDU>
Subject:      Re: [SECURITY] new version of procmail with security fixes
To:	BUGTRAQ@NETSPACE.ORG

debian-security-announce@LISTS.DEBIAN.ORG writes:
>A new version of procmail has been released which fixes a couple
>of buffer overflows and has extra security checks.
>
>We recommend you upgrade your procmail package immediately.

As the person who fixed most of those overflows I suppose I should
elaborate on this.

First off, for non-debian users, the source to the current procmail
release can be fetched from:

	http://www.procmail.org/procmail.tar.gz
	ftp://ftp.procmail.org/pub/procmail/procmail.tar.gz

PGP signatures can be found next to the those (".sig"), made by the key
with keyid 0x4A25D351, availible on the keyservers or at
	http://www.procmail.org/pgp-key.html

Mirrors will be announced on the procmail webpage
(http://www.procmail.org/) as they are confirmed.


All versions of procmail previous to 3.12 could overflow heap allocated
buffers, either when given a sufficiently long command line argument,
or during expansions while processing procmailrc files.  If the later
occurs during the processing of /etc/procmailrc on systems where
procmail is installed setuid root or is run as the local delivery
agent, root access may be obtainable.  If procmail is installed setgid,
then the command line overflow exposes that group, but not (directly)
root.  Overflows that occur while processing user procmailrc files may
give out setgid and/or that user's access.


The details are similar to any other program with heap-allocated buffer
overflow.  None of overflows directly involved the message being
processed, but rather were triggered by expansions in the user's
procmailrc file.  Since only the user can change that, there should be
no problem...except that:

a) procmail is installed setgid mail on many systems and (depending on
   the spool configuration and system) may not have given up those
   privileges, and
b) many rcfiles extract data from the message (say, the contents of a
   header, or a snippet of the body) and then use that in later
   conditions.

(a) means that a local user may be able to obtain setgid mail rights,
while (b) means that remote exploits may be possible.  However, even
when self-inflicted with no gain, crashing on overflow is just rude.

Closing the overflows has been a matter of simply checking, in the
correct places, that there's enough space to do what needs to be done.
While I can't rule out doing so in the future, we have not moved to a
scheme of dynamically allocating everything, partly because I don't
have the time to debug such a scheme, and partly because it isn't clear
that it would even be the right thing to do (think DOS-attacks).

I'm not claiming to have fixed them all -- I've been following this
list too long to be that stupid -- but we have our eyes open and are
actively working on catching them when we find them.  Bug reports and
comments should be sent to <bug@procmail.org>.

I have not heard of or seen any exploits.  (Waste of typing to say that.)


Philip Guenther

----------------------------------------------------------------------
guenther@gac.edu		UNIX Systems and Network Administrator
Gustavus Adolphus College	St. Peter, MN 56082-1498
Source code never lies: it just misleads (Programming by Purloined Letter?)