In response to the recent Debian
procmail update, Philip
Guenther gives us a general overview of the problem, and a
solution for non-Debian users.
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 .
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?)