OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Is postfix vulnerable to the Linux setcap bug?
From: Wietse Venema (wietseporcupine.org)
Date: Thu Jun 08 2000 - 12:08:26 CDT

I can confirm that Postfix has no set-[ug]id programs that attempt
to shed privileges. The optionally set-gid program is postdrop
which runs with the same set-gid privileges from start to end.

<begin rant>

I purposely avoided set-[ug]id programs in the Postfix design. The
feature is hard to deploy securely, and opens new vulnerabilities
whenever the system is extended. For example, "safe" set-[ug]id
programs became vulnerable after the introduction of shared libraries,
after the /proc filesystem, and now again with capabilities. Each
time, implementors had to learn to jump new hoops in order to plug
the holes.

<end rant>

        Wietse

Liviu Daia:
> On 8 June 2000, Lorens Kockum <lk-pfubigears.solsoft.com> wrote:
> > It's not a sendmail bug, it's a Linux bug... capabilites are not
> > dropped correctly in certain cases.
> >
> > http://sendmail.net/?feed=000607linuxbug
>
> The setcap(2) affect binaries SETUID TO ROOT. None of the Postfix
> binaries is setuid. I'd still recommend staying away from Linux though. :-)
>
> I'm attaching the bugtraq announce.
>
> Regards,
>
> Liviu Daia
>
>
> ----- Forwarded message from Sendmail Security <sendmail-securitySENDMAIL.ORG> -----
>
> From: Sendmail Security <sendmail-securitySENDMAIL.ORG>
> To: BUGTRAQSECURITYFOCUS.COM
> Subject: Sendmail Workaround for Linux Capabilities Bug
> Date: Wed, 7 Jun 2000 18:42:34 -0700
>
> SENDMAIL SECURITY TEAM ADVISORY
>
> Sendmail Workaround for Linux Capabilities Bug
>
> The Sendmail Consortium and Sendmail, Inc. has been informed of a
> serious problem in the Linux kernel that can be used to get root
> access. This is not a sendmail security problem, although sendmail
> is one of the vectors for this attack.
>
> PROBLEM
>
> There is a bug in the Linux kernel capability model for versions
> through 2.2.15 that allows local users to get root. Sendmail is
> one of the programs that can be attacked this way. This problem
> may occur in other capabilities-based kernels.
>
> SOLUTION
>
> The correct fix is to update your Linux kernel to version
> 2.2.16. This is the only way to ensure that other programs
> running on Linux cannot be attacked by this bug.
>
> WORKAROUND
>
> Sendmail 8.10.2 has added a check to see if the kernel has
> this bug, and if so will refuse to run. This version also
> does more detailed checks on certain system calls, notably
> setuid(2), to detect other possible attacks. Although there
> are no known attacks, this version is strongly recommended,
> whether or not you have a vulnerable kernel.
>
> Sendmail 8.10.2 can be obtained from:
>
> ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.10.2.tar.gz
> ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.10.2.tar.Z
> ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.10.2.tar.sig
>
> and has MD5 signatures:
>
> acb8b6f50869a058a9baaa4fb4692c4b sendmail.8.10.2.tar.Z
> 00705e5ca3412604cebd052e0d7aefcd sendmail.8.10.2.tar.gz
> 92dca37fb68a2a44f02c292656c123b6 sendmail.8.10.2.tar.sig
>
> You only need one of the first two files (either the gzip'ed
> version or the compressed version). The .sig file is a PGP
> signatures of the tar file (after uncompressing it). It is
> signed with the Sendmail Signing Key/2000, available on the web
> site (http://www.sendmail.org/) or on the public key servers.
>
> Note however that installing this sendmail patch does not
> fully protect you from attack. Other programs are probably
> vulnerable.
>
> ACKNOWLEDGEMENTS
>
> Several people contributed to this advisory. Wojciech Purczynski
> of Elzab Soft first identified the problem. Alan Cox verified
> and patched the Linux kernel bug. Gregory Neil Shapiro and other
> members of the Sendmail Consortium helped identify the problem
> and produce the sendmail workaround.
>
> DETAILS OF THE VULNERABILITY
>
> The problem lies in the setcap(2) call, which is not documented
> on most Linux-based systems (we think there might be a man page
> on Mandrake). This call, based on the unratified Posix 1e draft,
> attempts to break down root permissions into a series of
> capabilities. Normally root has all capabilities and normal
> users have none of the capabilities.
>
> One such capability is the ability of a process to do an
> arbitrary setuid(2) call. As documented in ISO/IEC 9945-1
> (ANSI/IEEE Std 1003.1) POSIX Part 1:
>
> 4.2.2.2 Description
> ...
> If {_POSIX_SAVED_IDS} is defined:
>
> (1) If the process has appropriate privileges, the
> setuid() function sets the real user ID, effective
> user ID, and the saved set-user-ID to uid.
>
> (2) If the process does not have the appropriate
> privileges, but uid is equal to the real user ID
> or the saved set-user-ID, the setuid() function
> sets the effective user ID to uid; the real user
> ID and saved set-user-ID remain unchanged by this
> function call.
>
> The CAP_SETUID capability represents the "appropriate privileges".
>
> Normally this would not be an issue, since a setuid root program
> would simply have capability reinstated. However, Linux has
> an added capability CAP_SETPCAP that controls the ability of a
> process to inherit capabilities; this capability does affect
> setuid programs. It is possible to set the capabilities such
> that a setuid program does not have "appropriate privileges."
> The effect of this is that a root program cannot fully give up
> its root privileges (since the saved set-user-ID cannot be
> reset).
>
> Note that checking the return value from setuid() is insufficient;
> the setuid(getuid()) succeeds even when the process does not have
> "appropriate privileges."
>
> The sendmail patch attempts a setuid(0) after a setuid(getuid());
> under normal circumstances this should fail (unless of course
> the real uid is root). If this setuid(0) succeeds, then the
> kernel has failed to properly give up permissions and sendmail
> will refuse to continue running.
>
> This problem can, of course, appear in any setuid root program
> that attempts to cede special permissions.
>
>
> ----- End forwarded message -----
>
> --
> Dr. Liviu Daia e-mail: Liviu.Daiaimar.ro
> Institute of Mathematics web page: http://www.imar.ro/~daia
> of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc
>
>
>
>