Mailinglist Archive: opensuse-security (465 mails)

< Previous Next >
Fwd: SUSEconfig weakens Postfix chroot security
  • From: JW <jw@xxxxxxxxxxxxxxxxxx>
  • Date: Tue, 04 Dec 2001 11:06:57 -0600
  • Message-id: <5.1.0.14.0.20011204110333.03a79f00@xxxxxxxxxxxxxxxxxxxxxxx>
Hello,

I hope it is appropriate to forward this to the list. Since it is SuSE specific I'll assume it is o.k.

It was sent to BugTraq this morning and I have not seen mention of it here yet.

I sincerely hope SuSE releases a fix for this, distributed through YOU.

Just thought at the very least it should be brought to the attention of the people subscribed to this list.

>Mailing-List: contact bugtraq-help@xxxxxxxxxxxxxxxxx; run by ezmlm
>List-Id: <bugtraq.list-id.securityfocus.com>
>From: Matthias Andree <matthias.andree@xxxxxxxxxxxxxxxxxxxx>
>To: bugtraq@xxxxxxxxxxxxxxxxx
>Subject: SUSEconfig weakens Postfix chroot security
>User-Agent: Mutt/1.3.22.1i
>
>### 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
> security@xxxxxxx and choeger@xxxxxxx 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.

----------------------------------------------------
Jonathan Wilson
System Administrator

Cedar Creek Software http://www.cedarcreeksoftware.com
Central Texas IT http://www.centraltexasit.com


< Previous Next >
This Thread
  • No further messages