Vulnerability Note VU#369347

OpenSSH vulnerabilities in challenge response handling

Original Release date: 26 Jun 2002 | Last revised: 06 Dec 2002

Overview

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.

Description

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


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

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


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

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 may 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 adminstrators 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.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Apple Computer Inc.Affected24 Jun 200202 Jul 2002
Compaq Computer CorporationAffected24 Jun 200216 Jul 2002
ConectivaAffected-27 Jun 2002
Cray Inc.Affected24 Jun 200227 Jun 2002
DebianAffected24 Jun 200227 Jun 2002
F5 NetworksAffected24 Jun 200217 Jul 2002
FreeBSDAffected24 Jun 200216 Jul 2002
Guardian Digital Inc. Affected24 Jun 200227 Jun 2002
Hewlett-Packard CompanyAffected24 Jun 200216 Jul 2002
IBMAffected24 Jun 200208 Aug 2002
MandrakeSoftAffected24 Jun 200227 Jun 2002
NETBSDAffected24 Jun 200208 Jul 2002
Nortel NetworksAffected24 Jun 200216 Jul 2002
OpenBSDAffected-26 Jun 2002
OpenPKGAffected-17 Jul 2002
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

Credit

The CERT/CC thanks Theo de Raadt and Markus Friedl of the OpenSSH project for their technical assistance in producing this document. The SKEY/BSD_AUTH vulnerability was discovered by Mark Dowd at ISS X-Force.

This document was written by Cory F Cohen.

Other Information

  • CVE IDs: CAN-2002-0639
  • CERT Advisory: CA-2002-18
  • Date Public: 24 Jun 2002
  • Date First Published: 26 Jun 2002
  • Date Last Updated: 06 Dec 2002
  • Severity Metric: 49.34
  • Document Revision: 38

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.