[Plug-security] [forward: Sendmail Workaround for Linux Capabilities Bug]

Rusty Carruth rustyc@inficad.com
Thu, 08 Jun 2000 09:22:58 -0700


Here's an alert I've not seen on su breakin ability (from an initial scan
of the info, it looks like this only affects people who are able
to log in to your computer, but don't pass on this upgrade
just because you MIGHT be safe!

rusty

> 
> Subject: Fwd: Sendmail Workaround for Linux Capabilities Bug
> 
> FYI - all your systems are probably vulnerable, regardless of whether you
> have sendmail installed or not.
> 
> Robin.
> 
> >Approved-By: aleph1@SECURITYFOCUS.COM
> >Delivered-To: bugtraq@lists.securityfocus.com
> >Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
> >X-Mailer: VM 6.75 under 21.2  (beta34) "Molpe" XEmacs Lucid
> >Date:         Wed, 7 Jun 2000 18:42:34 -0700
> >Reply-To: Sendmail Security <sendmail-security@SENDMAIL.ORG>
> >Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
> >From: Sendmail Security <sendmail-security@SENDMAIL.ORG>
> >Subject:      Sendmail Workaround for Linux Capabilities Bug
> >X-To:         auscert@auscert.org.au, cert@cert.org
> >X-cc:         vendor-sec@lst.de
> >To: BUGTRAQ@SECURITYFOCUS.COM
> >X-Status:
> >X-Keywords:
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >                 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.
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: PGPfreeware 5.0 for non-commercial use
> >Charset: noconv
> >
> >iQCVAwUBOT73YsApykAW9MzpAQExvgP+MjRKFw8IGCmzIdODUF6mIQ18/TETHtHb
> >AE7qUZs+0NBYhceF7Qn+UggKF53bBBc1gqvBmyqkJ8MFgEWNcx2cQawTxDU2G9wi
> >7H95ffC9KxsVcO9CNU/1EmezLzJbQxAdgNNheHQ3MYVIBY32Bfdd3bO3oJ4uyXGd
> >8UqMMIAkB3U=
> >=E2ZI
> >-----END PGP SIGNATURE-----
> 
> <<  End forwarded message
> 
> Rusty Carruth
> Voice:  (480) 345-3621               Schlumberger ATE
> FAX:    (480) 345-8793               7855 S. River Parkway, Suite 116
> Pager:  (888) --------               Tempe, AZ 85284-1825
> Pager email:
> Email:  rcarruth@Tempe.tt.slb.com