8652907 2002-06-26 16:41 +0200 /96 rader/ Markus Friedl <markus@openbsd.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-27 07:08 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Mottagare: Bugtraq (import) <22843>
Ärende: OpenSSH Security Advisory (adv.iss)
------------------------------------------------------------
From: Markus Friedl <markus@openbsd.org>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20020626144150.GA3124@folly>
1. Versions affected:
All versions of OpenSSH's sshd between 2.9.9 and 3.3
contain an input validation error that can result in
an integer overflow and privilege escalation.
OpenSSH 3.4 and later are not affected.
OpenSSH 3.2 and later prevent privilege escalation
if UsePrivilegeSeparation is enabled in sshd_config.
OpenSSH 3.3 enables UsePrivilegeSeparation by
default.
Although OpenSSH 2.9 and earlier are not affected
upgrading to OpenSSH 3.4 is recommended, because
OpenSSH 3.4 adds checks for a class of potential bugs.
2. Impact:
This bug can be exploited remotely if
ChallengeResponseAuthentication is enabled in sshd_config.
Affected are at least systems supporting
s/key over SSH protocol version 2 (OpenBSD, FreeBSD
and NetBSD as well as other systems supporting
s/key with SSH). Exploitablitly of systems
using PAM in combination has not been verified.
3. Short-Term Solution:
Disable ChallengeResponseAuthentication in sshd_config.
or
Enable UsePrivilegeSeparation in sshd_config.
4. Solution:
Upgrade to OpenSSH 3.4 or apply the following patches.
5. Credits:
ISS.
Appendix:
A:
Index: auth2-chall.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v
retrieving revision 1.18
diff -u -r1.18 auth2-chall.c
--- auth2-chall.c 19 Jun 2002 00:27:55 -0000 1.18
+++ auth2-chall.c 26 Jun 2002 09:37:03 -0000
@@ -256,6 +256,8 @@
authctxt->postponed = 0; /* reset */
nresp = packet_get_int();
+ if (nresp > 100)
+ fatal("input_userauth_info_response: nresp too big %u", nresp);
if (nresp > 0) {
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i < nresp; i++)
B:
Index: auth2-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth2-pam.c,v
retrieving revision 1.12
diff -u -r1.12 auth2-pam.c
--- auth2-pam.c 22 Jan 2002 12:43:13 -0000 1.12
+++ auth2-pam.c 26 Jun 2002 10:12:31 -0000
@@ -140,6 +140,15 @@
nresp = packet_get_int(); /* Number of responses. */
debug("got %d responses", nresp);
+
+ if (nresp != context_pam2.num_expected)
+ fatal("%s: Received incorrect number of responses "
+ "(expected %u, received %u)", __func__, nresp,
+ context_pam2.num_expected);
+
+ if (nresp > 100)
+ fatal("%s: too many replies", __func__);
+
for (i = 0; i < nresp; i++) {
int j = context_pam2.prompts[i];
(8652907) /Markus Friedl <markus@openbsd.org>/------
8652683 2002-06-26 19:03 -0400 /433 rader/ CERT Advisory <cert-advisory@cert.org>
Sänt av: owner-root@lysator.liu.se
Importerad: 2002-06-27 02:46 av Brevbäraren
Extern mottagare: cert-advisory@cert.org
Mottagare: Bellman -- The Recursive Hacker <19393>
Mottaget: 2002-06-27 08:01
Mottagare: Bugtraq (import) <22845>
Sänt: 2002-06-27 07:23
Ärende: CERT Advisory CA-2002-18 OpenSSH Vulnerabilities in Challenge Response
------------------------------------------------------------
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org
Message-ID: <CA-2002-18.1@cert.org>
-----BEGIN PGP SIGNED MESSAGE-----
CERT Advisory CA-2002-18 OpenSSH Vulnerabilities in Challenge Response
Handling
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
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.
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
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
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
http://www.kb.cert.org/vuls/id/369347
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
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
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.
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). 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.
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 availble for download as soon as possible. When
available the new packages can be downloaded from:
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
OpenSSH
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.
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 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:
http://www.cert.org/advisories/CA-2002-18.html
______________________________________________________________________
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
U.S.A.
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
http://www.cert.org/CERT_PGP.key
If you prefer to use DES, please call the CERT hotline for
more information.
Getting security information
CERT publications and other security information are available
from our web site http://www.cert.org/
To subscribe to the CERT mailing list for advisories and
bulletins, send email to majordomo@cert.org. Please include in
the body of your message
subscribe cert-advisory
* "CERT" and "CERT Coordination Center" are registered in the
U.S. Patent and Trademark Office.
______________________________________________________________________
NO WARRANTY
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
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQCVAwUBPRpGQ6CVPMXQI2HJAQEC1QP/eqRQzNmK0B1h5DvNLtTFmey8wOpfrSpX
PHbJ2Ps4IYfu+OepUH7UEDGoYkza5jpIoqz+UeRmJfq51IU2RCwcfOOEkbLslra7
yFEM9oWIVCwC6cOvlkzlXA6cd2uX6YonNxYZ/6tUs3BmQVKxCrzDXBEWV6HC3zis
1qgt5S8MRYM=
=+K4J
-----END PGP SIGNATURE-----
(8652683) /CERT Advisory <cert-advisory@cert.org>/(Ombruten)
8652934 2002-06-26 21:08 +0200 /108 rader/ Markus Friedl <markus@openbsd.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-27 07:29 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Mottagare: Bugtraq (import) <22846>
Ärende: Revised OpenSSH Security Advisory (adv.iss)
------------------------------------------------------------
From: Markus Friedl <markus@openbsd.org>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20020626190810.GA4989@folly>
This is the 2nd revision of the Advisory.
1. Versions affected:
Serveral versions of OpenSSH's sshd between 2.3.1 and 3.3
contain an input validation error that can result in an
integer overflow and privilege escalation.
All versions between 2.3.1 and 3.3 contain a bug in the
PAMAuthenticationViaKbdInt code.
All versions between 2.9.9 and 3.3 contain a bug in the
ChallengeResponseAuthentication code.
OpenSSH 3.4 and later are not affected.
OpenSSH 3.2 and later prevent privilege escalation if
UsePrivilegeSeparation is enabled in sshd_config. OpenSSH
3.3 enables UsePrivilegeSeparation by default.
Although some earlier versions are not affected upgrading
to OpenSSH 3.4 is recommended, because OpenSSH 3.4 adds
checks for a class of potential bugs.
2. Impact:
This bug can be exploited remotely if
ChallengeResponseAuthentication
is enabled in sshd_config.
Affected are at least systems supporting s/key over
SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD
as well as other systems supporting s/key with SSH).
Exploitablitly of systems using
PAMAuthenticationViaKbdInt
has not been verified.
3. Short-Term Solution:
Disable ChallengeResponseAuthentication in sshd_config.
and
Disable PAMAuthenticationViaKbdInt in sshd_config.
Alternatively you can prevent privilege escalation
if you enable UsePrivilegeSeparation in sshd_config.
4. Solution:
Upgrade to OpenSSH 3.4 or apply the following patches.
5. Credits:
ISS.
Appendix:
A:
Index: auth2-chall.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v
retrieving revision 1.18
diff -u -r1.18 auth2-chall.c
--- auth2-chall.c 19 Jun 2002 00:27:55 -0000 1.18
+++ auth2-chall.c 26 Jun 2002 09:37:03 -0000
@@ -256,6 +256,8 @@
authctxt->postponed = 0; /* reset */
nresp = packet_get_int();
+ if (nresp > 100)
+ fatal("input_userauth_info_response: nresp too big %u", nresp);
if (nresp > 0) {
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i < nresp; i++)
B:
Index: auth2-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth2-pam.c,v
retrieving revision 1.12
diff -u -r1.12 auth2-pam.c
--- auth2-pam.c 22 Jan 2002 12:43:13 -0000 1.12
+++ auth2-pam.c 26 Jun 2002 10:12:31 -0000
@@ -140,6 +140,15 @@
nresp = packet_get_int(); /* Number of responses. */
debug("got %d responses", nresp);
+
+ if (nresp != context_pam2.num_expected)
+ fatal("%s: Received incorrect number of responses "
+ "(expected %u, received %u)", __func__, nresp,
+ context_pam2.num_expected);
+
+ if (nresp > 100)
+ fatal("%s: too many replies", __func__);
+
for (i = 0; i < nresp; i++) {
int j = context_pam2.prompts[i];
(8652934) /Markus Friedl <markus@openbsd.org>/------