__________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Center ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN SSH Secure Shell Remote Root Exploit Vulnerability [SSH Secure Shell 3.0.0 Security Advisory] July 23, 2001 21:00 GMT Number L-121 ______________________________________________________________________________ PROBLEM: A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0 for Unix. NOTE: Older versions of SSH may be vulnerable to this exploit as well. PLATFORM: - Red Hat Linux 6.1 thru 7.1 - Solaris 2.6 thru 2.8 - HP-UX 10.20 - HP-UX 11.00 - Caldera Linux 2.4 - Suse Linux 6.4 thru 7.0 Please note that other platforms not listed here may also be vulnerable. DAMAGE: If the field containing the encrypted password is two or fewer characters, a problem during password authentication could allow account access with any password, including the null password. SOLUTION: Follow the suggestions outlined below. ______________________________________________________________________________ VULNERABILITY The risk is HIGH. Unauthorized users could potentially log into ASSESSMENT: vulnerable accounts using any password including the null password. ______________________________________________________________________________ LINKS: CIAC BULLETIN: http://www.ciac.org/ciac/bulletins/l-121.shtml ORIGINAL BULLETIN: http://www.ssh.com/products/ssh/exploit.cfm ______________________________________________________________________________ [***** Start SSH Secure Shell 3.0.0 Security Advisory *****] A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0, for Unix only, concerning accounts with password fields consisting of two or fewer characters. Unauthorized users could potentially log in to these accounts using any password, including an empty password. This affects SSH Secure Shell 3.0.0 for Unix only. This is a problem with password authentication to the sshd2 daemon. The SSH Secure Shell client binaries (located by default in /usr/local/bin) are not affected. SSH Secure Shell 3.0.1 fixes this problem. Please note that if using a form of authentication other than password, AND password authentication is disabled, you are NOT VULNERABLE to this issue. PLATFORMS IMPACTED: Red Hat Linux 6.1 thru 7.1 Solaris 2.6 thru 2.8 HP-UX 10.20 HP-UX 11.00 Caldera Linux 2.4 Suse Linux 6.4 thru 7.0 Please note that other platforms not listed here may also be vulnerable. PLATFORMS NOT IMPACTED: Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable. Please note that other platforms not listed here may also be immune. SCOPE Some stock machines which have default locked accounts running SSH Secure Shell 3.0 are vulnerable to arbitrary logins. This is a serious problem with Solaris, for example, which uses the sequence "NP" to indicate locked administrative accounts such as "lp", "adm", "bin" etc. Some Linux machines which have accounts with !! in the etc/passwd or /etc/shadow such as xfs or gdm are also vulnerable. Since it is relatively easy to become root after gaining access to certain accounts, we consider this a potential root exploit. DETAILED DESCRIPTION During password authentication, if the field containing the encrypted password in /etc/shadow, /etc/password, etc. is two or less characters long, SSH 3.0.0 will allow anyone to access that account with ANY password. The bug is in the code that compares the result of calling crypt(pw, salt) with the value of the encrypted password in the /etc/shadow (or /etc/password) file. SSH Secure Shell Server 3.0.0 does a bounded string compare bounded to the length of the value stored in aforementioned file (2 characters in this case) against the return value of crypt(). The return value of crypt() is 13 characters, with the first two characters being the salt value itself. The salt value used is the first two characters of the encrypted password in /etc/shadow (or /etc/password). A 2 character string comparison between the 2 character encrypted password in /etc/shadow, and the 13 character crypt() return value, whose first two characters ARE the 2 characters from the password in /etc/shadow. The strings match, and the 3.0.0 daemon then accepts the password, no matter what is input. SOLUTIONS Preferred Immediately upgrade to SSH Secure Shell 3.0.1 which will be available on our e-commerce site http://commerce.ssh.com shortly, and is available on the ftp site now - ftp://ftp.ssh.com/pub/ssh A patch for 3.0.0 source code is also available there. Alternative work-arounds Disable password authentication to the SSH Secure Shell daemon (sshd2) in the /etc/ssh2/sshd2_config and use another form of authentication such as public key, SecurID, Kerberos, certificates, Smart Cards, or hostbased to authenticate your users. These alternative authentication methods are NOT VULNERABLE. Please see our SSH Secure Shell support web pages for more information on how to enable these authentication methods. OR If you cannot disable password authentication fully, limit access to the sshd2 daemon to allow only users with entries in the /etc/passwd and /etc/shadow which exceed two characters. This can be done using the AllowUsers, AllowGroups, DenyUsers, and DenyGroups keywords in the /etc/ssh2/sshd2_config file. See our SSH Secure Shell support web pages http://www.ssh.com/support/ssh and man sshd2_config for more information. OR Assign a valid password for each account. Because it is possible that assigning a password to some system accounts could cause problems on some operating systems, this work-around is limited and is provided only as a last-resort alternative. OR Use the following patch in the source code: """ File /lib/sshsession/sshunixuser.c Function ssh_user_validate_local_password Location near line 953, before /*Authentication is accepted if the encrypted passwords are identical. */ Add lines if (strlen(correct_passwd) < 13) return FALSE; "" We apologize for any inconvenience this may cause. SSH Communications Security takes security issues very seriously, and a CERT advisory and submission to Bugtraq regarding this issue have been submitted. Please make every effort to ensure that your systems are protected using one of the above methods as quickly as possible. As this information becomes widely known, your systems could be at even greater risk if appropriate measures are not taken. SSH is fully committed to serving and supporting our users and products. While we may not be able to address each request for information on this issue individually, we will make publicly available any relevant information possible which addresses your questions and concerns. CREDITS This vulnerability was found and reported by an anonymous system administrator at the Helsinki University of Technology and by Andrew Newman of Yale University. [***** End SSH Secure Shell 3.0.0 Security Advisory *****] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of SSH Communications Security for the information contained in this bulletin. _______________________________________________________________________________ CIAC, the Computer Incident Advisory Center, 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 (7x24) FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@ciac.org Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ Anonymous FTP: ftp.ciac.org 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) L-112: Cisco SN 5420 Storage Router Vulnerabilities L-113: Microsoft Outlook View Control Exposes Unsafe Functionality L-114: Hewlett-Packard login Vulnerability L-115: Hewlett-Packard dlkm Vulnerability L-116: Lightweight Directory Access Protocol (LDAP) Vulnerabilities L-117: The Code Red Worm L-118: Hewlett-Packard ftpd and ftp Vulnerability L-119: Hewlett-Packard mkacct Program Vulnerability L-120: Cisco "Code Red" Worm Impact