yet another! aren't computers fun? =jay
OpenSSH Vulnerabilities in Challenge Response Handling ------------------------------------------------------------------------ SUMMARY There are two related vulnerabilities in the challenge response handling code in OpenSSH versions 2.3.1p1 through 3.3. They may allow a remote intruder to execute arbitrary code as the user running SSHd (often root). The first vulnerability affects OpenSSH versions 2.9.9 through 3.3 that have the challenge response option enabled and that use SKEY or BSD_AUTH authentication. The second vulnerability affects PAM modules using interactive keyboard authentication in OpenSSH versions 2.3.1p1 through 3.3, regardless of the challenge response option setting. Additionally, a number of other possible security problems have been corrected in OpenSSH version 3.4. DETAILS Vulnerable systems: * OpenSSH versions 2.3.1p1 through 3.3 Immune systems: * OpenSSH version 3.4 Two related vulnerabilities have been found in the handling of challenge responses in OpenSSH. The first vulnerability is an integer overflow in the handling of the number of responses received during challenge response authentication. If the challenge response configuration option is set to yes and the system is using SKEY or BSD_AUTH authentication then a remote intruder may be able to exploit the vulnerability to execute arbitrary code. This vulnerability is present in versions of OpenSSH 2.9.9 through 3.3. An exploit for this vulnerability is reported to exist. This vulnerability is partially described in a recent ISS security advisory available at: <http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20584> http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20584 The second vulnerability is a buffer overflow involving the number of responses received during challenge response authentication. Regardless of the setting of the challenge response configuration option, systems using PAM modules that use interactive keyboard authentication (PAMAuthenticationViaKbdInt), may be vulnerable to the remote execution of code. At this time, it is not known if this vulnerability is exploitable. Both vulnerabilities are corrected by the patches in a recent OpenSSH security advisory available from <http://www.openssh.com/txt/preauth.adv> http://www.openssh.com/txt/preauth.adv Both vulnerabilities exploit features present only in version 2 of the SSH protocol. Impact: A remote attacker can execute code with the privileges of the user running the SSHd (often root). These vulnerabilities may also be used to cause a denial-of-service condition. Solution: Upgrade to OpenSSH version 3.4 These vulnerabilities are eliminated by upgrading to OpenSSH version 3.4, which is available from the OpenSSH web site at: <http://www.openssh.com> http://www.openssh.com OpenSSH version 3.4 will correct several other software defects with potential security implications not described in this advisory. Apply a patch from your vendor A patch for this problem is included in the OpenSSH advisory at: <http://www.openssh.com/txt/preauth.adv> http://www.openssh.com/txt/preauth.adv This patch may be manually installed with minor changes to correct these vulnerabilities in all affected versions of OpenSSH. Please note that applying the patches described in the OpenSSH advisory does not correct the other software defects with potential security implications not described in this advisory. If your vendor has provided a patch to correct these vulnerabilities, you may want to apply their patch rather than upgrading your version of SSHd. System administrators may want to confirm whether their vendor's patch includes the other possible vulnerabilities corrected in OpenSSH 3.4. More information about vendor-specific patches can be found in the vendor section of this document. Because the publication of this advisory was unexpectedly accelerated, statements from all of the affected vendors were not available at publication time. We will update this document as vendors provide additional information. Disable SSH protocol version 2 Since both vulnerabilities are present only in protocol version 2 features, disabling version 2 of the protocol will prevent both vulnerabilities from being exploited. Typically, this is accomplished by adding the following line to /etc/ssh/sshd_config: Protocol 1 This option may set to "2, 1" by default. System administrators should be aware that disabling protocol version 2 might prevent the SSHd daemon from accepting connections in certain configurations. Applying one or both of the configuration changes described below may be a less disruptive workaround for this problem. Disable challenge response authentication For OpenSSH versions greater than 2.9, system administrators can disable the vulnerable portion of the code by setting the "ChallengeResponseAuthentication" configuration option to "no" in their SSHd configuration file. Typically, this is accomplished by adding the following line to /etc/ssh/sshd_config: ChallengeResponseAuthentication no This option may be enabled (set to "yes") by default. This workaround should prevent the first vulnerability from being exploited if SKEY or BSD_AUTH authentication is used. It will not prevent the possible exploitation of the vulnerability via PAM interactive keyboard authentication. Disable PAM authentication via interactive keyboard For OpenSSH versions greater than 2.9, system administrators can disable the vulnerable portion of the code affecting the PAM authentication issue by setting the "PAMAuthenticationViaKbdInt" configuration option to "no" in their SSHd configuration file. Typically, this is accomplished by adding the following line to /etc/ssh/sshd_config: PAMAuthenticationViaKbdInt no This option may be disabled (set to "no") by default. This workaround should prevent the second vulnerability from being exploited if PAM interactive keyboard authentication is used. It will not prevent the possible exploitation of the vulnerability via SKEY or BSD_AUTH authentication. Disable both options in older versions of OpenSSH For OpenSSH versions between 2.3.1p1 and 2.9, system administrators will instead need to set the following options in their SSH configuration file: KbdInteractiveAuthentication no ChallengeResponseAuthentication no Setting both of these options is believed to prevent the exploitation of the vulnerabilities regardless of which authentication mechanisms are used. Use privilege separation to minimize impact System administrators running OpenSSH versions 3.2 or 3.3 may be able to reduce the impact of this vulnerability by enabling the "UsePrivilegeSeparation" configuration option in their SSHd configuration file. Typically, this is accomplished by adding the following line to /etc/ssh/sshd_config: UsePrivilegeSeparation yes This workaround does not prevent these vulnerabilities from being exploited, however due to the privilege separation mechanism, the intruder may be limited to a constrained chroot environment with restricted privileges. This workaround will not prevent these vulnerabilities from creating a denial-of-service condition. Not all operating system vendors have implemented the privilege separation code, and on some operating systems, it may limit the functionality of OpenSSH. System administrators are encouraged to carefully review the implications of using the workaround in their environment, and use a more comprehensive solution if one is available. The use of privilege separation to limit the impact of future vulnerabilities is encouraged. Appendix A. - Vendor Information This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Compaq Computer Corporation SOURCE: Compaq Computer Corporation, a wholly owned subsidiary of Hewlett-Packard Company and Hewlett-Packard Company HP Services. Software Security Response Team x-ref:SSRT2263 At the time of writing this document, Compaq is currently investigating the potential impact to HP Tru64 UNIX, commercial version of SSH for V5.1a. As further information becomes available notice will be provided of the completion/availability of any necessary patches through standard product and security bulletin announcements and be available from your normal HP Services support channel. Caldera Caldera OpenLinux OpenSSH has neither the S/KEY nor BSD Auth features compiled in, so it is not vulnerable to the Challenge/Response vulnerability. We do have the ChallengeResponseAuthentication option on by default, however, so to be safe, we recommend that the option be disabled in the sshd_config file. In addition, the sshd_config PAMAuthenticationViaKbdInt option is off by default, so OpenLinux is not vulnerable to the other alleged vulnerability in a default configuration, either. However, Caldera recommends that this option be disabled if it has been enabled by the system administrator. Cray, Inc. Cray, Inc. has found the OpenSSH released in Cray Open Software 3.0 to be vulnerable. Please see Field Notice 5105 and spr 722588 for fix information. Debian Debian 2.2 (the current stable release) is not affected by these problems. The current versions of our "testing" distribution, to become Debian 3.0, and our "unstable" distribution, are both affected by default. We recommend that users be certain that both: ChallengeResponseAuthentication no And PAMAuthenticationViaKbdInt no Are present and uncommented in /etc/ssh/sshd_config (and that the server is restarted). In addition, we recommend the use of version 3.3p1, now available from security.debian.org (DSA-134). Stable users do not need to upgrade and may wish to wait until the packages have received better testing. We intend to provide 3.4p1 packages in the near future. EnGarde Guardian Digital ships OpenSSH in all versions of EnGarde Secure Linux. Version 3.3p1 was introduced by ESA-20020625-015 on June 25, 2002. This update introduces privilege separation. All users are strongly urged to upgrade to this version as soon as possible. An upgrade to version 3.4p1 (which properly fixes the bugs) will be made available sometime in the next few days. Hewlett-Packard Company Hewlett-Packard provides a version of SSH: HP-UX Secure Shell (T1471AA) for HP-UX versions 11.00 and 11i. We are investigating to determine whether this product is vulnerable. IBM Corporation IBM's AIX operating system does not ship with OpenSSH; however, OpenSSH is available for installation on AIX via the Linux Affinity Toolkit. The version included on the CD containing the Toolkit is vulnerable to the latest discovered vulnerability discussed here, as is the version of OpenSSH available for downloading from the IBM Linux Affinity website. Anyone running this version is advised to follow the recommendations above to limit their vulnerability. We working with the changes for version 3.4 and will have a new package available for download as soon as possible. When available the new packages can be downloaded from: <http://www6.software.ibm.com/dl/aixtbx/aixtbx-p> http://www6.software.ibm.com/dl/aixtbx/aixtbx-p This site contains Linux Affinity applications containing cryptographic algorithms, and new users of this site are asked to register first. Lotus Lotus products are not vulnerable to this problem. Mandrake Software MandrakeSoft released OpenSSH 3.3p1 in updates Monday night to mitigate this vulnerability. Updates to OpenSSH 3.4p1 will be available for download later this week. Microsoft Corporation Microsoft products are not affected by the issues detailed in this advisory. Network Appliance NetApp systems are not vulnerable to this problem. OpenBSD See <http://www.openbsd.org/errata.html#sshd> http://www.openbsd.org/errata.html#sshd OpenSSH See <http://www.openssh.com/txt/preauth.adv> http://www.openssh.com/txt/preauth.adv Process Software MultiNet, TCPware, and SSH for OpenVMS are not affected by the problems outlined in this advisory. RedHat Inc. Red Hat Linux versions 7, 7.1, 7.2, and 7.3 as well as Red Hat Linux Advanced Server version 2.1 ship with OpenSSH. The Red Hat Linux OpenSSH packages were not compiled with either BSD_AUTH or SKEY enabled, therefore in order to be vulnerable to this issue a user would need to have enabled the configuration option "PAMAuthenticationViaKbdInt" in their SSHd configuration file (the default is disabled). We are continuing to investigate this vulnerability and will release updated packages where appropriate. SGI At this time, SGI does not ship OpenSSH as a part of IRIX. The OpenSSH privilege separation code mostly works with IRIX, but it uses a flag to mmap that is not in IRIX (MAP_ANON) for compression so you cannot have both on at the same time. IRIX does not ship with PAM so many of the PAM issues are not issues for us. SuSE Linux Further details about the bugs in question have turned up by now, indicating that SuSE Linux products are not affected to the mentioned problem unless the administrator of an OpenSSH installation has actively added the configuration option (PAMAuthenticationViaKbdInt) to the daemon configuration file /etc/ssh/sshd_config to turn this option on. In other words: We are not vulnerable by default. We have quickly published update packages with the workaround as described in your announcement, but due to incompatibilities and errors in the newer package, we think about downgrading back to our 2.9.9p2 version packages as well as one newer version on one of our newer products. The decision about the downgrade has not been made yet, but we are positive about that we will publish another set of update packages that effectively remove the weakness from the package. After all, the currently offered packages for download from our ftp server ( <ftp://ftp.suse.com/pub/suse/i386/update/> ftp://ftp.suse.com/pub/suse/i386/update/) represent an emergency fix that should be considered incomplete considering the quality standards at SuSE. ADDITIONAL INFORMATION The information has been provided by <mailto:[EMAIL PROTECTED]> CERT Advisory. ======================================== This bulletin is sent to members of the SecuriTeam mailing list. To unsubscribe from the list, send mail with an empty subject line and body to: [EMAIL PROTECTED] In order to subscribe to the mailing list, simply forward this email to: [EMAIL PROTECTED] ==================== ==================== DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages. _______________________________________________ Bits mailing list [EMAIL PROTECTED] http://www.sugoi.org/mailman/listinfo/bits
