Sendmail Workaround for Linux Capabilities Bug (fwd)

[Robert Watson]

Thought this might be of interest to the list.

Linux capabilities are implemented such that root processes have all
capabilities, which are used to authorize privileged requests, and may
give up these capabilities.  In addition, my understanding is that the
kernel tracks whether or not a process has demonstrated it is
"capability-aware" to determine certain inheritence semantics.  I haven't
worked with this behavior in Linux, so don't claim to have a complete
understanding, and would welcome a more complete (and possibly more
correct) description.

In my FreeBSD implementation (in the process of being committed to the
5.0-CURRENT tree), the ability for uid0 to have complete privilege is
toggled using a kernel MIB value, and without the MIB value enabled, the
root process has no special capabilities, instead relying on file flags to
gain the capability. 

I'm not sure which of these techniques the authors of POSIX.1e had in
mind, and to what extent that influences the possibility of vulnerability
to this bug.  In any case, it represents an interesting situation in which
attempting to decompose a central concentration of privilege by
introducing a new model for authorization results in a weakness.  It also
reminds us that having well-defined syntax and semantics for
capability-management calls would be a good idea :-).

By the end of the week, stub syscalls will be committed to FreeBSD.
Currently, library support for capabilities has been committed, as well as
man pages.  Gradually over the next couple of weeks, support for
individual capabilities will be committed.  Early access to some of this
code is available via www.trustedbsd.org.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

---------- Forwarded message ----------
Date: Wed, 7 Jun 2000 18:42:34 -0700
From: Sendmail Security <sendmail-security at SENDMAIL.ORG>
To: BUGTRAQ at SECURITYFOCUS.COM
Subject: Sendmail Workaround for Linux Capabilities Bug

| Signature by unknown keyid: 0x16F4CCE9

		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.

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message