SUSEconfig weakens Postfix chroot security

From: Matthias Andree (matthias.andreeat_private-dortmund.de)
Date: Tue Dec 04 2001 - 07:19:34 PST

  • Next message: Microsoft Security Response Center: "RE: Stack overflow in all Internet Explorer Versions!!"

    ### INTRODUCTION
    
    Postfix is a mail transfer agent for UNIX-like systems written by Wietse
    Venema. "Postfix attempts to be fast, easy to administer, and secure,
    while at the same time being sendmail compatible enough to not upset
    existing users." (quote from http://www.postfix.org/)
    
    SuSE Linux is a Linux distribution, which the vendor claims as being the
    most comprehensive, stable and secure operating system on the market
    (http://www.suse.de/en/index.html). SuSE Linux ships - among a lot of
    other packages - with Postfix and Sendmail.
    
    
    ### SUMMARY OF THE ISSUE
    
    SuSEconfig sets up the chroot for Postfix insecurely. It gives away
    system libraries and configuration files to the user that Postfix
    processes in the chroot jail run as, this is not a security issue in
    itself, but it weakens one of the security barriers that chroot is
    supposed to impose.
    
    SuSEconfig also tampers with the permissions in Postfix' mail submission
    directories, which can prevent Postfix from cleaning up after itself,
    leading to filled disks and making tracking local malicious users more
    difficult.
    
    
    ### SCOPE
    
    SuSE Linux systems that use a SuSE Postfix RPM:
    
    I cannot do research on all the SuSEconfig.postfix versions out there,
    so if you run a different version than any of those shown below, check
    out yourself with "grep chown /sbin/conf.d/SuSEconfig".  For the -63 RPM
    mentioned below, this yields:
    
            chown -R postfix /var/spool/postfix/*
    
    I suspect that all Postfix RPMs that SuSE packaged before December 2001
    have this weak spot.
    
    --- AFFECTED SUSE RPMS
    
        (I only list here versions that I checked personally.)
    
        unconditionally:
        postfix-19991231pl08-26 (SuSE 7.0 CD)
        postfix-19991231pl13-3  (ftp.suse.com update area for 7.0)
        postfix-20010228-4      (ftp.suse.com update area for 7.1)
    
        if POSTFIX_CHROOT="yes":
        postfix-20010228pl04-20 (SuSE 7.3 CD)
    
        if POSTFIX_CHROOT="yes" and POSTFIX_CREATECF="yes":
        postfix-20010228pl04-63 (ftp.suse.com update area for 7.3)
    
    --- UNAFFECTED
    
        * SuSE Linux systems that run other mail transfer agents than Postfix
        are unaffected.
    
        * SuSE Linux systems that run a manually installed copy of Postfix
        (from source of from another RPM maintainer) and that have properly
        removed SuSE's RPM (particularly, /sbin/conf.d/SuSEconfig.postfix*
        must have been erased) are also unaffected.
    
    
    ### "VENDOR" (MAINTAINER) STATUS
    
    DATE OF CONTACT: 2001-11-28 13:41:10 (UTC)
    
    1. The Software itself is unaffected. I thank Wietse Venema who helped
       finding the bug and showed it is not a problem with Postfix or the
       Postfix default installation.
    
    2. The Packager who provided the configuration script: I contacted
       securityat_private and choegerat_private by email about the problems
       below on 2001-11-28 (last Wednesday) at 13:41 UTC, I asked them to
       respond within 120 hours, and offered to wait longer with announcing
       this problem publically in case they have reasons to defer that.
    
       My mail was received by mail.suse.de[213.95.15.193] as queue-ID
       0B7BC1E535 at that day, 13:41:10 UTC, but I got no reply, and no new
       Postfix RPM had appeared at ftp.suse.com until 14:00 UTC today,
       2001-12-03.
    
    I can no longer withhold this information from the public; with the
    public release I hope to avoid that other users run into the problems
    described below.
    
    
    ### ISSUE ###
    
    --- WEAKNESSES IN SUSECONFIG.POSTFIX
    
    These explanations refer to the postfix-20010228pl04-63 RPM for SuSE
    Linux 7.3 i386, as found on ftp.suse.com, unless otherwise stated.
    
    1. (security) (applies to all versions listed AFFECTED above) SuSEconfig
       gives away the files it places in the etc/*, lib/*, usr/* chroot
       environment to the user that is to be jailed there.  In the unlikely
       event that a bug in a Postfix daemon (no such bugs are known to me at
       this time) allows a break-in, the attacker can replace any lib/* file
       and screw up royally.
    
       The chroot rationale is to set up a controlled, small, working
       environment for a process without special privileges. The additional
       security this can provide is undermined when the process that is run
       in the chroot can change that "controlled" environment.
    
       I therefore recommend that the chroot libraries and configuration
       files belong to the privileged root user and be configured to mode
       755 or 644 so that in no event the process kept in the chroot can
       tamper with the libraries and files.
    
    2. SuSEconfig.postfix' chroot setup code contains the line
    
            chown -R postfix /var/spool/postfix/*
    
       This constitues a race against Postfix daemons (no matter if the
       Postfix system is running or stopped).
    
       When a mail is injected by means of Postfix' /usr/sbin/sendmail
       compatibility program (no matter if that calls upon postdrop itself),
       the injected mail file belongs to the user running the sendmail
       compatibility program.
    
       When SuSEconfig runs (on systems that have a configuration option to
       use chroot, this needs to be "yes") and a local mail injection goes
       wrong at the same time, the injecting daemon (sendmail or postdrop)
       can no longer remove the broken mail file. This can get nasty if the
       injected mail is large, because Postfix can no longer remove the file
       that it rejected as "too large". Filled disks may result.
    
       Also, after this chown command has completed, it is more difficult to
       figure out which user has injected the offending mail if malice is
       suspected.
    
    --- STRANGENESS IN PACKAGING UPDATES
    
    3. SuSE have included the essence of Postfix-20010228-patch07 and
       patch08, but stuck with -pl04 otherwise, omitting patch05 and
       patch06.  The rationale why SuSE chose to not simply update to the
       latest bugfix level which does not add features or change documented
       behaviour is unexplained and remains unclear. (Please note that since
       the release of Postfix-20010228, Postfix-19991231 is unmaintained in
       favor of the 20010228 official non beta stable release.)
    
    
    ### ACKNOWLEDGEMENTS
    
       I thank these persons for their help with this issue:
    
       W. Z. Venema         - for helping to find the bug
       C. Ludwig            - for proofreading this announcement
       R. Hildebrandt       - for proofreading this announcement
    
    
    ### ORIGINATOR/COPYRIGHT/LICENSE/WARRANTIES
    
    (C) 2001 by Matthias Andree.
    
    Permission is granted to copy and/or distribute this document under the
    terms of the GNU Free Documentation License, Version 1.1 or any later
    version published by the Free Software Foundation; with the Invariant
    Sections being THE WHOLE DOCUMENT (each section is invariant). No Front-
    or Back-Cover Texts are provided. The GNU Free Documentation License is
    available at http://www.gnu.org/licenses/fdl.html.
    



    This archive was generated by hypermail 2b30 : Tue Dec 04 2001 - 10:51:21 PST