debian-security-announceat_private 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 <bugat_private>. I have not heard of or seen any exploits. (Waste of typing to say that.) Philip Guenther ---------------------------------------------------------------------- guentherat_private UNIX Systems and Network Administrator Gustavus Adolphus College St. Peter, MN 56082-1498 Source code never lies: it just misleads (Programming by Purloined Letter?)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:27 PDT