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: <>

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: <>
>From: Matthias Andree <matthias.andree@xxxxxxxxxxxxxxxxxxxx>
>To: bugtraq@xxxxxxxxxxxxxxxxx
>Subject: SUSEconfig weakens Postfix chroot security
>User-Agent: Mutt/
>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
>SuSE Linux is a Linux distribution, which the vendor claims as being the
>most comprehensive, stable and secure operating system on the market
>( SuSE Linux ships - among a lot of
>other packages - with Postfix and Sendmail.
>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
>### 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.
> (I only list here versions that I checked personally.)
> unconditionally:
> postfix-19991231pl08-26 (SuSE 7.0 CD)
> postfix-19991231pl13-3 ( update area for 7.0)
> postfix-20010228-4 ( update area for 7.1)
> if POSTFIX_CHROOT="yes":
> postfix-20010228pl04-20 (SuSE 7.3 CD)
> postfix-20010228pl04-63 ( update area for 7.3)
> * 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.
>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[] as queue-ID
> 0B7BC1E535 at that day, 13:41:10 UTC, but I got no reply, and no new
> Postfix RPM had appeared at 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 ###
>These explanations refer to the postfix-20010228pl04-63 RPM for SuSE
>Linux 7.3 i386, as found on, 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.
>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.)
> 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
>(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

Jonathan Wilson
System Administrator

Cedar Creek Software
Central Texas IT

< Previous Next >
This Thread
  • No further messages