[NEWS] OpenSSH Vulnerabilities in Challenge Response Handling

From: support@securiteam.com
Date: 06/27/02

From: support@securiteam.com
To: list@securiteam.com
Date: Thu, 27 Jun 2002 15:04:26 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  OpenSSH Vulnerabilities in Challenge Response Handling


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.


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

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.

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

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

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

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


At the time of writing this document, Compaq is currently investigating
the potential impact to HP Tru64 UNIX, commercial version of SSH for

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

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


The information has been provided by <mailto:cert-advisory@cert.org> CERT


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: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


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.

Relevant Pages