-----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Linux Kernel Capability Vulnerability August 15, 2000 21:00 GMT Number K-064 ______________________________________________________________________________ PROBLEM: A vulnerability exists in the setcap(2) call. This call will attempt to break down root permisssions into a series of capabilities. It may be possible to set the capabilities so that a setuid program cannot fully give up its root privileges thus allowing a normal user elevated privileges. PLATFORM: All linux kernels 2.XXX through 2.2.15. DAMAGE: Local users can gain root privileges. SOLUTION: Due to the many programs using the linux kernel capability, it is strongly suggested that all users upgrade to linux kernel 2.2.16. Information on workarounds for sendmail, SGI Linux, and Sendmail, Inc. switches follow. ______________________________________________________________________________ VULNERABILITY The risk is MEDIUM, the vulnerability has been publicly ASSESSMENT: discussed. ______________________________________________________________________________ - -----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 Sendmail Advisory ******] [****** Begin SGI Advisory ******] - -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SGI Security Advisory Title: Linux Kernel Capability Vulnerability Number: 20000802-01-P Date: August 14, 2000 ______________________________________________________________________________ SGI provides this information freely to the SGI user community for its consideration, interpretation, implementation and use. SGI recommends that this information be acted upon as soon as possible. SGI provides the information in this Security Advisory on an "AS-IS" basis only, and disclaims all warranties with respect thereto, express, implied or otherwise, including, without limitation, any warranty of merchantability or fitness for a particular purpose. In no event shall SGI be liable for any loss of profits, loss of business, loss of data or for any indirect, special, exemplary, incidental or consequential damages of any kind arising from your use of, failure to use or improper use of any of the instructions or information in this Security Advisory. ______________________________________________________________________________ - - ----------------------- - - --- Issue Specifics --- - - ----------------------- Sendmail, Inc. (http://www.sendmail.com/) reported a vulnerability in the capability model of the Linux kernel which can lead to a root compromise. SGI ProPack for Linux uses a modified kernel optimized for SGI Linux hardware. This kernel is based on the standard kernel available from http://www.kernel.org/ with SGI patches from http://oss.sgi.com/ SGI has investigated the issue and recommends the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures be implemented on ALL vulnerable SGI systems. This issue will be corrected in future releases of SGI ProPack for Linux. - - -------------- - - --- Impact --- - - -------------- SGI ProPack for Linux comes with a modified Linux kernel and is installed by default on various Linux distributions. For more information, see: http://oss.sgi.com/projects/ or http://support.sgi.com/linux/ A local user account on the vulnerable system is required in order to exploit capability model of the Linux kernel. This Linux kernel vulnerability can lead to a root compromise. This Linux kernel vulnerability was reported by Sendmail, Inc.: http://www2.sendmail.com/alert/ and http://sendmail.net/?feed=000607linuxbug This Linux kernel vulnerability has been publicly discussed in Usenet newsgroups and mailing lists. - - -------------------------- - - --- Temporary Solution --- - - -------------------------- Unfortunately, there are no immediate or temporary workarounds for this issue. This issue can only be addressed with the installation of an RPM. - - ---------------- - - --- Solution --- - - ---------------- This issue is fixed in 2.2.16 Linux kernel. For more information see: http://www.linux.org.uk/VERSION/relnotes.2216.html SGI ProPack 1.4 plans to use the 2.2.16 Linux kernel as its base. SGI has back-ported the fix to older Linux kernels in ProPack 1.2 and 1.3. SGI ProPack 1.2 is based on the 2.2.13 Linux kernel. SGI ProPack 1.3 is based on the 2.2.15 Linux kernel. Version Vulnerable Patch # Other Actions --------------- ----------- ------- ------------- SGI ProPack 1.2 yes 3993 SGI ProPack 1.3 yes 3991 SGI ProPack 1.4 no Patches are available via the web, anonymous FTP and from your SGI service/support provider. SGI patches and RPMs for Linux can be found at: http://support.sgi.com/linux/ and click on patches link and http://oss.sgi.com/projects/sgilinux-combined/download/security-fixes/ SGI patches for Windows NT or 2000 can be found at: http://support.sgi.com/nt/ IRIX 5.2-6.4 Recommended/Required Patch Sets can be found at: http://support.sgi.com/irix/ and ftp://patches.sgi.com/support/patchset/ IRIX 6.5 Maintenance Release Streams can be found at: http://support.sgi.com/irix/ and ftp://patches.sgi.com/support/relstream/ IRIX Security Patchsets can be found at: http://www.sgi.com/support/security/ and ftp://sgigate.sgi.com/patches/ SGI Security Advisories can be found at: http://www.sgi.com/support/security/ and ftp://sgigate.sgi.com/security/ The primary SGI anonymous FTP site for security information and patches is sgigate.sgi.com (204.94.209.1). Security information and patches can be found in the ~ftp/security and ~ftp/patches directories, respectively. For security and patch management reasons, ftp.sgi.com (mirror of sgigate) lags behind and does not do a real-time update of ~ftp/security and ~ftp/patches - - ------------------------ - - --- Acknowledgments ---- - - ------------------------ SGI wishes to thank the users of the Internet Community at large for their assistance in this matter. - - ----------------------------------------- - - --- SGI Security Information/Contacts --- - - ----------------------------------------- If there are questions about this document, email can be sent to cse-security-alert@sgi.com. ------oOo------ SGI provides security information and patches for use by the entire SGI community. This information is freely available to any person needing the information and is available via anonymous FTP and the Web. The primary SGI anonymous FTP site for security information and patches is sgigate.sgi.com (204.94.209.1). Security information and patches are located under the directories ~ftp/security and ~ftp/patches, respectively. The SGI Security Headquarters Web page is accessible at the URL: http://www.sgi.com/support/security/ For issues with the patches on the FTP sites, email can be sent to cse-security-alert@sgi.com. For assistance obtaining or working with security patches, please contact your SGI support provider. ------oOo------ SGI provides a free security mailing list service called wiretap and encourages interested parties to self-subscribe to receive (via email) all SGI Security Advisories when they are released. Subscribing to the mailing list can be done via the Web (http://www.sgi.com/support/security/wiretap.html) or by sending email to SGI as outlined below. % mail wiretap-request@sgi.com subscribe wiretap end ^d In the example above, is the email address that you wish the mailing list information sent to. The word end must be on a separate line to indicate the end of the body of the message. The control-d (^d) is used to indicate to the mail program that you are finished composing the mail message. ------oOo------ SGI provides a comprehensive customer World Wide Web site. This site is located at http://www.sgi.com/support/security/ . ------oOo------ For reporting *NEW* SGI security issues, email can be sent to security-alert@sgi.com or contact your SGI support provider. A support contract is not required for submitting a security report. ______________________________________________________________________________ This information is provided freely to all interested parties and may be redistributed provided that it is not altered in any way, SGI is appropriately credited and the document retains and includes its valid PGP signature. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBOZiEpbQ4cFApAP75AQEncwP/X4MImJVjA9DLcgo2nTlWbouKPkfrp7eS eikuIp+0+BIddhmYaPwfHABTLWR5I4wbFQfaodRN4OjHb/dZYj9eMw/qdMjarNIF aI2LHxhDf+w3Wl6a0uTn3/tiMJ66NaApHImSZqNUcRn0XNtLqVhbtwtRkD9KbqYr aw0/AZW1nSk= =yPgl - -----END PGP SIGNATURE----- [****** End SGI Advisory ******] [****** Begin Sendmail Inc Alert ******] Sendmail Workaround for Linux Capabilities Bug PROBLEM There is a bug in the Linux kernel capability model for versions from 2.XXX through 2.2.15 that allows local users to get root. Sendmail is one of the programs that can be attacked this way. Please note that this is NOT a Sendmail security issues, but rather a Linux issue that can manifest itself in the sendmail program. This problem may also occur in other capabilities-based kernels. FIX 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. WORKAROUND If you are currently unable to obtain an upgrade from your vendor, we strongly recommend that you download the Sendmail 2.0.5 patch. Sendmail Switch 2.0.5 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. Please download the correct product-specified version of the patch indicated below: Sendmail Single Switch 2.0.5 patch Sendmail Secure Switch 2.0.5 patch Sendmail Multi Switch with Openswitch MTA Sendmail Multi Switch with Cryptoswitch MTA Open Source sendmail 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 XXX 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_XXX 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 Switch 2.0.5 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. Copyright © 1999-2000 Sendmail Inc., all rights reserved. [****** End Sendmail Inc Alert ******] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of Sendmail, Inc., SGI, and sendmail.org for the information contained in this bulletin. _______________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), use one of the following methods to contact CIAC: 1. Call the CIAC voice number 925-422-8193 and leave a message, or 2. Call 888-449-8369 to send a Sky Page to the CIAC duty person or 3. Send e-mail to 4498369@skytel.com, or 4. Call 800-201-9288 for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ (or http://ciac.llnl.gov -- they're the same machine) Anonymous FTP: ftp.ciac.org (or ciac.llnl.gov -- they're the same machine) Modem access: +1 (925) 423-4753 (28.8K baud) +1 (925) 423-3331 (28.8K baud) PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) K-063: Netscape Java Vulnerability K-062: Vulnerabilities in Lotus Notes Domino Aired at DefCon 8 K-061: Microsoft Office HTML and IE Script Vulnerabilities K-060: Microsoft's Malformed E-Mail Header Vulnerability K-059: Microsoft DTS Password Vulnerability K-058: OpenSSH UseLogin Vulnerability K-057: Microsoft Active Setup Download Vulnerability K-056: IRIX WorkShop cvconnect(1M) Vulnerability K-055: HP Web JetAdmin Vulnerability K-054: Vulnerability in Linux wu-ftpd -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition iQCVAwUBOZrboLnzJzdsy3QZAQEflwP8DkQ3EU/l+soR+GVMWYsQ3uBKzzrZ4Yr8 wh4OlbFTIa2uRFU2UCpG9c5a5YxoHAoMqe0Lt48M5kMaCfQymkw7zbGd8Qy+DtFK iFkANyVcjuOLrzPEe/wuBuLPvboPoqsO8G/ZTkQ1Ra6JANRNvdOo8yHg2dI4J+o9 SwaA847tdRA= =fRAa -----END PGP SIGNATURE-----