Re: tlug: [sendmail-security@example.com: Sendmail Workaround for Linux Capabilities Bug]

["Thomas O'Dowd" <tom@example.com>]

What's the lists feelings on qmail? When I used to have a REAL job, we
used sendmail but now that I've got my own machines setup at home, I 
don't use anything other than qmail. It was so easy to setup and the
security of it is very attractive. I haven't seen any problems reported.
sendmails config file is just way to hacky, but then again, that probably
appeals to most of you sick people :-)

Tom.

On Thu, Jun 08, 2000 at 03:59:30PM +0900, Jonathan Byrne wrote:
> One we might all want to take a look at.
> 
> Jonathan
> 
> 
> 
> ----- Forwarded message from Sendmail Security <sendmail-security@example.com> -----
> > -----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 -----
> 
> 
> -----------------------------------------------------------------------
> Next Meeting (w/ YLUG): June 16 (Fri) 19:00 Mizonoguchi Marui Family 12F
> Next Technical Meeting: July 8 (Sat)  13:30 Topic: TBA
> -----------------------------------------------------------------------
> more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan

-- 
Thomas O'Dowd
tom@example.com
-----------------------------------------------------------------------
Next Meeting (w/ YLUG): June 16 (Fri) 19:00 Mizonoguchi Marui Family 12F
Next Technical Meeting: July 8 (Sat)  13:30 Topic: TBA
-----------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan