Buffer overflow in sshd in OpenSSH 2.3.1 through 3.3 may allow remote attackers to execute arbitrary code via a large number of responses during challenge response authentication when OpenBSD is using PAM modules with interactive keyboard authentication (PAMAuthenticationViaKbdInt).

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.

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

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.

Updated openssh packages are now available for Red Hat Linux Advanced Server. These updates fix an input validation error in OpenSSH.

OpenSSH provides an implementation of the SSH (secure shell) protocol used for logging into and executing commands on remote machines.

Versions of the OpenSSH server between 2.3.1 and 3.3 contain an input validation error that can result in an integer overflow and privilege escalation.

At this time, Red Hat does not believe that the default installation of OpenSSH on Red Hat Linux is vulnerable to this issue; however a user would be vulnerable if the configuration option 'PAMAuthenticationViaKbdInt' is enabled in the sshd configuration file (it is not enabled by default).

We have applied the security fix provided by the OpenSSH team to these errata packages which are based on OpenSSH 3.1p1. This should minimize the impact of upgrading to our errata packages.

All users of OpenSSH should update to these errata packages which are not vulnerable to this issue.

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

ID	Name	Product	Family	Type	Severity
55992	SunSSH < 1.1.1 / 1.3 CBC Plaintext Disclosure	Nessus	Misc.	Remote	critical
14971	Debian DSA-134-4 : ssh - remote exploit	Nessus	Debian Local Security Checks	Local	critical
1987	OpenSSH < 3.4 Multiple Remote Overflows	Nessus Network Monitor	SSH		high
13944	Mandrake Linux Security Advisory : openssh (MDKSA-2002:040-1)	Nessus	Mandriva Local Security Checks	Local	critical
12309	RHEL 2.1 : openssh (RHSA-2002:131)	Nessus	Red Hat Local Security Checks	Local	critical
11031	OpenSSH < 3.4 Multiple Remote Overflows	Nessus	Gain a shell remotely	Remote	critical

Detections

Analytics

CVE-2002-0640

critical

Tenable Plugins

critical

critical

high

critical

critical

critical