ISS X-Force released an advisory about an OpenSSH 'Remote Challenge Vulnerability'. Unfortunately, the advisory was incorrect on some points, leading to widespread confusion about the impact of this vulnerability. No version of OpenSSH in Debian is affected by the SKEY and BSD_AUTH authentication methods described in the ISS advisory.
However, Debian does include OpenSSH servers with the PAM feature described as vulnerable in the later advisory by the OpenSSH team.
(This vulnerable feature is authentication using PAM via the keyboard-interactive mechanism [kbdint].) This vulnerability affects OpenSSH versions 2.3.1 through 3.3. No exploit is currently known for the PAM/kbdint vulnerability, but the details are publicly known. All of these vulnerabilities were corrected in OpenSSH 3.4.

In addition to the vulnerabilities fixes outlined above, our OpenSSH packages version 3.3 and higher support the new privilege separation feature from Niels Provos, which changes ssh to use a separate non-privileged process to handle most of the work. Vulnerabilities in the unprivileged parts of OpenSSH will lead to compromise of an unprivileged account restricted to an empty chroot, rather than a direct root compromise. Privilege separation should help to mitigate the risks of any future OpenSSH compromise.

Debian 2.2 (potato) shipped with an ssh package based on OpenSSH 1.2.3, and is not vulnerable to the vulnerabilities covered by this advisory. Users still running a version 1.2.3 ssh package do not have an immediate need to upgrade to OpenSSH 3.4. Users who upgraded to the OpenSSH version 3.3 packages released in previous iterations of DSA-134 should upgrade to the new version 3.4 OpenSSH packages, as the version 3.3 packages are vulnerable. We suggest that users running OpenSSH 1.2.3 consider a move to OpenSSH 3.4 to take advantage of the privilege separation feature. (Though, again, we have no specific knowledge of any vulnerability in OpenSSH 1.2.3. Please carefully read the caveats listed below before upgrading from OpenSSH 1.2.3.) We recommend that any users running a back-ported version of OpenSSH version 2.0 or higher on potato move to OpenSSH 3.4.

The current pre-release version of Debian (woody) includes an OpenSSH version 3.0.2p1 package (ssh), which is vulnerable to the PAM/kbdint problem described above. We recommend that users upgrade to OpenSSH 3.4 and enable privilege separation. Please carefully read the release notes below before upgrading. Updated packages for ssh-krb5 (an OpenSSH package supporting kerberos authentication) are currently being developed. Users who cannot currently upgrade their OpenSSH packages may work around the known vulnerabilities by disabling the vulnerable features: make sure the following lines are uncommented and present in /etc/ssh/sshd_config and restart ssh

  PAMAuthenticationViaKbdInt no ChallengeResponseAuthentication no

There should be no other PAMAuthenticationViaKbdInt or ChallengeResponseAuthentication entries in sshd_config.

That concludes the vulnerability section of this advisory. What follows are release notes related to the OpenSSH 3.4 package and the privilege separation feature. URLs for the OpenSSH 3.4 packages are at the bottom.

Some notes on possible issues associated with this upgrade :

  - This package introduces a new account called `sshd' that     is used in the privilege separation code. If no sshd     account exists the package will try to create one. If     the account already exists it will be re-used. If you do     not want this to happen you will have to fix this     manually.
  - (relevant for potato only) This update adds a back-port     of version 0.9.6c of the SSL library. This means you     will have to upgrade the libssl0.9.6 package as well.

  - (relevant for potato only) This update uses version 2 of     the SSH protocol by default (even if configured to     support version 1 of the SSH protocol). This can break     existing setups where RSA authentication is used. You     will either have to

    - add -1 to the ssh invocation to keep using SSH       protocol 1 and your existing keys, or
    - change the Protocol line in /etc/ssh/ssh_config       and/or/etc/ssh/sshd_config to 'Protocol 1,2' to try       protocol 1 before protocol 2, or

    - create new rsa or dsa keys for SSH protocol 2

  - sshd defaults to enabling privilege separation, even if     you do not explicitly enable it in /etc/ssh/sshd_config.
  - ssh fall-back to rsh is no longer available.

  - (relevant for potato only) Privilege separation does not     currently work with Linux 2.0 kernels.

  - Privilege separation does not currently work with PAM     authentication via the KeyboardInteractive mechanism.

  - Privilege separation causes some PAM modules which     expect to run with root privileges to fail.

  - If for some reason you cannot use privilege separation     at this time due to one of the issues described above,     you can disable it by adding 'UsePrivilegeSeparation no'     to your/etc/ssh/sshd_config file.

Some issues from previous OpenSSH 3.3p1 packages corrected in this advisory (not a complete changelog) :

  - (relevant for potato only) the installation question,     'do you want to allow protocol 2 only' no longer     defaults to 'yes' for potato packages. Users who     answered yes to this question and also chose to     regenerate their sshd_config file found that they could     no longer connect to their server via protocol 1. See     /usr/doc/ssh/README.Debian for instructions on how to     enable protocol 1 if caught in this situation. Since the     default in the potato packages is now 'no', this should     not be an issue for people upgrading from version 1.2.3     in the future.
  - (relevant for potato only) the ssh package no longer     conflicts with rsh-server, nor does it provide an rsh     alternative

  - installation will no longer fail if users choose to     generate protocol 1 keys

Again, we regret having to release packages with larger changes and less testing than is our usual practice; given the potential severity and non-specific nature of the original threat we decided that our users were best served by having packages available for evaluation as quickly as possible. We will send additional information as it comes to us, and will continue to work on the outstanding issues.

The version of SunSSH running on the remote host has an information disclosure vulnerability.  A design flaw in the SSH specification could allow a man-in-the-middle attacker to recover up to 32 bits of plaintext from an SSH-protected connection in the standard configuration.  An attacker could exploit this to gain access to sensitive information.

Note that this version of SunSSH is also prone to several additional issues but Nessus did not test for them.

An input validation error exists in the OpenSSH server between versions 2.3.1 and 3.3 that can result in an integer overflow and privilege escalation. This error is found in the PAMAuthenticationViaKbdInt code in versions 2.3.1 to 3.3, and the ChallengeResponseAuthentication code in versions 2.9.9 to 3.3. OpenSSH 3.4 and later are not affected, and OpenSSH 3.2 and later prevent privilege escalation if UsePrivilegeSeparation is enabled; in OpenSSH 3.3 and higher this is the default behaviour of OpenSSH.

To protect yourself, users should be using OpenSSH 3.3 with UsePrivilegeSeparation enabled (see MDKSA:2002-040). However, it is highly recommended that all Mandrake Linux users upgrade to version 3.4 which corrects these errors.

There are a few caveats with this upgrade, however, that users should be aware of :

  - On Linux kernel 2.2 (the default for Mandrake Linux     7.x), the use of Compression and UsePrivilegeSeparation     are mutually exclusive. You can use one feature or the     other, not both; we recommend disabling Compression and     using privsep until this can be resolved.

  - Using privsep may cause some PAM modules which expect to     run with root privilege to fail. For instance, users     will not be able to change their password if they     attempt to log into an account with an expired password.

If you absolutely must use one of these features that conflict with privsep, you can disable it in /etc/ssh/sshd_config by using :

UsePrivilegeSeparation no

However, if you do this, be sure you are running OpenSSH 3.4. Updates to OpenSSH will be made available once these problems are resolved.

According to its banner, the remote host appears to be running OpenSSH version 3.4 or older. Such versions are reportedly affected by multiple flaws. An attacker may exploit these vulnerabilities to gain a shell on the remote system.

Note that several distributions patched this hole without changing the version number of OpenSSH. Since Nessus solely relied on the banner of the remote SSH server to perform this check, this might be a false positive.

If you are running a RedHat host, make sure that the command :
          rpm -q openssh-server 	  Returns :
	openssh-server-3.1p1-6

そのバナーによると、リモートホストは、OpenSSH バージョン 3.4 または以降を実行しているようです。このようなバージョンは、報告されているところによれば複数の欠陥の影響を受けます。攻撃者は、これらの脆弱性を悪用して、リモートシステムでシェルを取得することがあります。

いくつかの配布では、OpenSSH のバージョン番号を変更せずに、この穴にパッチが当てられていることに、注意してください。Nessus は、この確認を実行するために、リモート SSH サーバーのバナーにのみ依存していたため、誤検知の可能性があります。

RedHat ホストを実行している場合、次のコマンドを確認してください：
          rpm -q openssh-server
	  
戻り :
	openssh-server-3.1p1-6

远程主机上运行的 SunSSH 版本存在信息泄露漏洞。SSH 规范中的设计缺陷可允许中间人攻击者从标准配置的受 SSH 保护的连接中恢复多达 32 位的明文。攻击者可利用这一点获取敏感信息的访问权限。

请注意，此 SunSSH 版本也易于发生多个其他问题，但 Nessus 未对其进行测试。

リモートホストで実行されているバージョンの SunSSH に情報漏洩脆弱性があります。SSH の仕様の設計上の欠陥により、中間攻撃者が、標準構成の SSH 保護接続から最大 32 ビットまでの平文を回収できることがあります。攻撃者はこれを悪用して、機密情報にアクセスすることがあります。

このバージョンの SunSSH はいくつかのその他の問題の影響も受けやすくなっていますが、Nessus はそれらの問題をテストしていないことに、注意してください。

遠端主機上安裝的 SunSSH 版本有資訊洩漏弱點。SSH 規格的設計瑕疵允許攔截式攻擊者在標準組態中從 SSH 受保護的連線復原多達 32 位元的純文字。攻擊者可惡意利用此弱點來存取敏感資訊。

請注意，此版本的 SunSSH 也容易發生其他多個問題，但 Nessus 並未測試這些問題。

根据标题，远程主机似乎正在运行 OpenSSH 3.4 或更早版本。有报告称此类版本受到多种缺陷的影响：攻击者可能利用这些漏洞来获得远程系统上的 shell。

请注意，有几次分发的版本已经修补了该漏洞，但没有改变 OpenSSH 的版本号。由于 Nessus 仅依赖于远程 SSH 服务器的标题来执行该校验，因此这可能是误报。

如果您运行的是 RedHat 主机，则确保命令：
          rpm -q openssh-server 	 返回值为：
	openssh-server-3.1p1-6

The remote host is running a version of OpenSSH which is older than 3.4. There is a flaw in this version that can be exploited remotely to give an attacker a shell on this host. Note that several distributions patched this hole without changing the version number of OpenSSH.

If you are running a RedHat host, make sure that the command :
rpm -q openssh-server
 Returns : openssh-server-3.1p1-6.

Note: NNM has solely relied on the banner of the SSH client to perform this check. Any backported patches or workarounds such as recompiling or edited configurations are not observable through the banner.

ID	Name	Product	Family	Published	Updated	Severity
14971	Debian DSA-134-4 : ssh - remote exploit	Nessus	Debian Local Security Checks	9/29/2004	1/4/2021	critical
55992	SunSSH < 1.1.1 / 1.3 CBC Plaintext Disclosure	Nessus	Misc.	8/29/2011	9/21/2020	critical
13944	Mandrake Linux Security Advisory : openssh (MDKSA-2002:040-1)	Nessus	Mandriva Local Security Checks	7/31/2004	1/6/2021	critical
11031	OpenSSH < 3.4 Multiple Remote Overflows	Nessus	Gain a shell remotely	6/25/2002	3/27/2024	critical
11031	OpenSSH < 3.4 の複数のリモートオーバーフロー	Nessus	Gain a shell remotely	6/25/2002	3/27/2024	critical
55992	SunSSH < 1.1.1 / 1.3 CBC 明文泄露	Nessus	Misc.	8/29/2011	9/21/2020	critical
55992	SunSSH < 1.1.1 / 1.3 CBC の平文での漏洩	Nessus	Misc.	8/29/2011	9/21/2020	critical
55992	SunSSH < 1.1.1 / 1.3 CBC 純文字洩漏	Nessus	Misc.	8/29/2011	9/21/2020	critical
11031	OpenSSH < 3.4 多重远程溢出	Nessus	Gain a shell remotely	6/25/2002	3/27/2024	critical
1987	OpenSSH < 3.4 Multiple Remote Overflows	Nessus Network Monitor	SSH	8/20/2004	3/6/2019	high

Detections

Analytics

Plugins Search

critical

critical

critical

critical

critical

critical

critical

critical

critical

high