|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Artem 'Zazoobr' Ignatjev 2:5020/1313.2 27 Jun 2002 20:23:22
To : All
Subject : Re: some [q]s
--------------------------------------------------------------------------------
.RFC-X-Complaints-To: usenet@p2.f20.n5095.z2.fidonet.net
.RFC-NNTP-Posting-Date: Thu, 27 Jun 2002 16:23:22 +0000 (UTC)
From: Artem 'Zazoobr' Ignatjev <timon@memphis.mephi.ru>
Artem 'Zazoobr' Ignatjev <timon@memphis.mephi.ru> wrote:
AZI> что за хитрый тред (оригинально - hogwash) идет в freebsd-security@ про
AZI> openssh (имею в виду, нет ли у кого информации, большей чем это было
AZI> описано в мессаге Theo de Raadt'a на тему что "надо вам апгрейд до
AZI> openssh 3.3. и privsep, а кто не делает - тому оппаньки"? )
Опппаньки!
Message-Id: <CA-2002-18.1@cert.org>
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org
Organization: CERT(R) Coordination Center - +1 412-268-7090
Subject: CERT Advisory CA-2002-18 OpenSSH Vulnerabilities in Challenge Response
-----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,
* Message split, to be continued *
--- Пятилеток уже нет, а пятилетний план остался - ведь сушили его на 5 лет
вперед!
* Origin: От создателя соков "Я" - водка "Ы?" (2:5020/1313.2@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
some [q]s |
Artem \'Zazoobr\' Ignatjev |
27 Jun 2002 18:33:21 |
 Re: some [q]s |
Artem \'Zazoobr\' Ignatjev |
27 Jun 2002 19:22:24 |
  Re: some [q]s |
Artem \'Zazoobr\' Ignatjev |
27 Jun 2002 20:23:22 |
|
[part 2] Re: some [q]s |
Artem \'Zazoobr\' Ignatjev |
27 Jun 2002 20:23:22 |
|
|
