CERT Advisory CA-2002-18 OpenSSH Vulnerabilities in Challenge Response

From: CERT Advisory (cert-advisory@cert.org)
Date: 06/27/02

Date: Wed, 26 Jun 2002 19:06:32 -0400 (EDT)
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org


CERT Advisory CA-2002-18 OpenSSH Vulnerabilities in Challenge Response

   Original release date: June 26, 2002
   Last revised: --
   Source: CERT/CC

   A complete revision history can be found at the end of this file.

Systems Affected

     * OpenSSH versions 2.3.1p1 through 3.3


   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.

I. 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.

   Vulnerability Note VU#369347 lists the vendors we contacted about this
   vulnerability. The vulnerability note is available from


II. 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.

III. 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

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

          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

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

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

 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


   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 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


   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


     PAMAuthenticationViaKbdInt no

   are present and uncommented in /etc/ssh/sshd_config (and that the
   server is restarted). Also, 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.


   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 availble for download as soon as possible. When available the
   new packages can be downloaded from:


   This site contains Linux Affinity applications containing
   cryptographic algorithms, and new users of this site are asked to
   register first.


   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

 Network Appliance

   NetApp systems are not vulnerable to this problem.


   See http://www.openbsd.org/errata.html#sshd


   See 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.


   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 isn't in IRIX (MAP_ANON) for compression so
   you can't have both on at the same time. IRIX doesn't ship with PAM so
   a lot of the PAM issues aren't issues for us.

   The CERT/CC thanks Theo de Raadt and Markus Friedl of the OpenSSH
   project for their technical assistance in producing this advisory.

   Author: Cory F. Cohen

   This document is available from:

CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890

   CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) /
   EDT(GMT-4) Monday through Friday; they are on call for emergencies
   during other hours, on U.S. holidays, and on weekends.

Using encryption

   We strongly urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from

   If you prefer to use DES, please call the CERT hotline for more

Getting security information

   CERT publications and other security information are available from
   our web site

   To subscribe to the CERT mailing list for advisories and bulletins,
   send email to majordomo@cert.org. Please include in the body of your

   subscribe cert-advisory

   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.

   Any material furnished by Carnegie Mellon University and the Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2002 Carnegie Mellon University.

   Revision History
     June 26, 2002: Initial release

Version: PGP 6.5.8


Relevant Pages

  • Re: [Full-disclosure] OpenSSH Security Advisory: gcmrekey.adv
    ... this vulnerability might permit code execution ... OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL ... that supports AES-GCM. ... Authentication Code context that is unused when the ...
  • NetBSD Security Advisory 2002-005: OpenSSH protocol version 2 challenge-response authentication
    ... OpenSSH has a vulnerability in protocol version 2 challenge-response ... - Turn off challenge-response authentication by having the following ... Releases of NetBSD 1.5.3 and NetBSD 1.6 are imminent. ...
  • [NEWS] OpenSSH Vulnerabilities in Challenge Response Handling
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... code in OpenSSH versions 2.3.1p1 through 3.3. ... The second vulnerability affects PAM modules using ...
  • Re: VDS FAQ - request for feedback
    ... If ChallengeResponseAuthentication is enabled on an OpenSSH server, ... OpenSSH servers with versions 2.9.9 through 3.3. ... authentication code to be executed as an unprivileged user. ... this vulnerability is largely based on which user executes authentication. ...
  • Another one?
    ... CERT Advisory CA-2002-18 OpenSSH Vulnerabilities in Challenge Response ... The first vulnerability affects OpenSSH versions 2.9.9 ...