search menu icon-carat-right cmu-wordmark

CERT Coordination Center

SSHD allows users to override "AllowedAuthentications" configuration thereby permitting users to provide any type of authentication

Vulnerability Note VU#341187

Original Release Date: 2002-05-21 | Last Revised: 2002-10-30

Overview

A remotely exploitable authentication vulnerability exists in the SSH Communications Security SSH Secure Shell server, and possibly other SSH servers.

Description

SSH is a program used to provide secure communications between hosts. Versions 3.0.0 - 3.1.1 of SSH Secure Shell for Servers does not properly enforce client authentication. As a result, an attacker can attempt to authenticate to an SSH server using password authentication.

There are two methods a client can use to authenticate to an SSH server. The first method is password authentication. This method is generally the easiest to set up, but the least secure. As long as the client has a valid username and password, they can gain access to the system running the SSH server. The second method is public key authentication. Public key authentication is one of the most secure methods to authenticate a user. For a client to gain access to a system using public key authentication, a copy of the client's public key must exist on the SSH server. The client must also have the private key in possession as well as the passphrase associated with the private key.

Impact

An attacker can attempt to authenticate to the vulnerable SSH server using password authentication, even if the server is configured to only allow public key authentication.

Solution

Apply a patch from your vendor or upgrade your software.

Use "RequiredAuthentications" keyword instead of "AllowedAuthentications" in sshd2_config:

RequiredAuthentications\thostbased, publickey

Vendor Information

341187
 
Affected   Unknown   Unaffected

F-Secure

Notified:  May 09, 2002 Updated:  May 21, 2002

Status

  Vulnerable

Vendor Statement

Please see http://www.f-secure.com/support/ssh/ssh2_allowedauthentications_vulnerability.shtml.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SSH Communications Security

Notified:  April 24, 2002 Updated:  May 20, 2002

Status

  Vulnerable

Vendor Statement

Please see http://www.ssh.com/products/ssh/advisories/authentication.cfm.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Cisco Systems Inc.

Notified:  May 10, 2002 Updated:  May 21, 2002

Status

  Not Vulnerable

Vendor Statement

Cisco is not affected.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nortel Networks

Notified:  May 10, 2002 Updated:  May 14, 2002

Status

  Not Vulnerable

Vendor Statement

Initial verification on a Solaris 8 server with OpenSSH 31p1
indicates that the "AllowedAuthentications" keyword is not used in
the OpenSSH server configuration. However, OpenSSH uses the following
two keywords for authentication configuration:

"PubkeyAuthentication"
"PasswordAuthentication"

The default value for both keywords is yes, which means the server
will allow both password and public key authentication. This is not
a vulnerability. But since all keywords including
"PasswordAuthentication" in the default OpenSSH sshd_config file are
commented out, users who want public key authentication method only
may mistakenly just uncomment "PubkeyAuthentication" keyword and
assign a yes value to it, not knowing that password authentication is
on by default even though that keyword is commented out in the
configuration file.

Workaround fix: For OpenSSH, if public key authentication is the only
method allowed, change the default value from "yes" to "no" for the
"PasswordAuthentication" keyword in sshd_config file.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Novell

Notified:  May 14, 2002 Updated:  May 23, 2002

Status

  Not Vulnerable

Vendor Statement

Novell does not ship ISC's DHCPD.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenSSH

Notified:  May 09, 2002 Updated:  May 15, 2002

Status

  Not Vulnerable

Vendor Statement

OpenSSH is not vulnerable to this particular problem.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Acknowledgements

The CERT/CC thanks SSH Communications Security for reporting this vulnerability to us.

This document was written by Ian A. Finlay.

Other Information

CVE IDs: None
Severity Metric: 10.13
Date Public: 2002-05-21
Date First Published: 2002-05-21
Date Last Updated: 2002-10-30 14:39 UTC
Document Revision: 50

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.