SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Security)  >   SSH Vendors:   SSH Communications
SSH May Allow Authorized Remote Users to Bypass Server Authentication Configuration Settings and Login Using Passwords When the Server is Configured to Prohibit the Use of Passwords
SecurityTracker Alert ID:  1004340
SecurityTracker URL:  http://securitytracker.com/id/1004340
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  May 21 2002
Impact:   Host/resource access via network, User access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): 3.0 - 3.1.1
Description:   A vulnerability was reported in SSH's client and server security software. An authorized remote user may be able to login using password authentication when the server has been configured to prohibit password authentication in favor of a stronger method.

SSH issued a security advisory warning of a potential flaw in the following SSH products:

SSH Secure Shell for Servers
SSH Secure Shell for Workstations (UNIX client running in server mode)
SSH Secure Shell for Windows Servers

In configurations where the "AllowedAuthentications" configuration options entry does not include the keyword "Password" as an authentication option, some clients using SSH v2 may be able to override this configuration and use password authentication even though the configuration is set to prohibit password authentication.

A remote user may be able to use password authentication using, for example, an old PuTTY client when the server configuration sshd2_config specifies:

AllowedAuthentications hostbased, publickey

The vendor reports that SSH Secure Shell for Workstations Windows client and SSH Secure Shell for Handhelds are not affected by this vulnerability.

Impact:   A remote user may be able to authenticate to the SSH server using password authentication when the server is configured to prohibit that method.

According to the vendor, this may affect systems that require stronger authentication methods, such as SecurID or digital certificates, but have set up weak passwords due to the fact that password authentication is not expected to take place at all.

Solution:   The vendor has released a fixed version (3.1.2) for SSH Secure Shell for Servers, SSH Secure Shell for Workstations (UNIX), and SSH Secure Shell for Windows Servers.

The vendor has also made a patch available, so customers can recompile with the patch.

The vendor has also described a workaround:

A workaround is to use "RequiredAuthentications" keyword instead of "AllowedAuthentications" in sshd2_config:

RequiredAuthentications hostbased, publickey

This will require both hostbased and publickey authentication to succeed before user is granted access to the system. The RequiredAuthentications will be enforced even if the client attempts to force a disallowed authentication method.

Vendor URL:  www.ssh.com/products/ssh/advisories/authentication.cfm (Links to External Site)
Cause:   State error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Jun 29 2004 (F-Secure Issues Fix) SSH May Allow Authorized Remote Users to Bypass Server Authentication Configuration Settings and Login Using Passwords When the Server is Configured to Prohibit the Use of Passwords
F-Secure has issued a fix.



 Source Message Contents

Subject:  SSH authentication bug


Security Advisory Regarding Vulnerability in SSH Secure Shell for
Servers, SSH Secure Shell for Workstations (UNIX client running in
server mode) and SSH Secure Shell for Windows Servers versions 3.0
through 3.1.1

SSH advises all users of commercial and non-commercial versions of SSH
Secure Shell for Servers, SSH Secure Shell for Workstations (UNIX client
running in server mode) and SSH Secure Shell for Windows Servers 3.0
through 3.11 to ensure the security of their systems. SSH Secure Shell
for Workstations Windows client and SSH Secure Shell for Handhelds are
NOT affected by this vulnerability. 

Short Explanation of the Vulnerability 

In configurations where "AllowedAuthentications" entry in the
configuration options (in SSH Secure Shell for Servers and SSH Secure
Shell for Windows Servers) does not include the keyword "Password" as an
authentication option, some clients based on secure shell protocol
version 2 may be capable of overriding the configuration and still
achieve password authentication contrary to the explicit denial of
password authentication. 

This may lead to a situation in which stronger authentication methods,
such as SecurID or digital certificates, are being enforced, but weak
passwords may have been defined by a system administrator due to the
fact that password authentication is not expected to take place at all.
As some secure shell protocol 2 based clients mey be capable to override
this system configuration, a possibility to exploit these weak passwords
may occur. 

For more complete technical description of the vulnerability, please see
paragraph "Technical Description of the Vulnerability" below. 

Solutions to this Vulnerability: 

- Workaround by using "RequiredAuthentications" 
- Upgrading to SSH Secure Shell for Servers, SSH Secure Shell for
Workstations (UNIX ) and SSH Secure Shell for Windows Servers 3.1.2 
- Recompiling with the patch 

SSH Secure Shell for Servers, SSH Secure Shell for Workstations and SSH
Secure Shell for Windows Servers version 3.1.2 fixes this problem. All
existing customers of SSH Secure Shell for Servers and SSH Secure Shell
for Windows Servers 3.0 through 3.1.1 have been provided with SSH Secure
Shell for Servers 3.1.2, SSH Secure Shell for Workstations 3.1.2 or SSH
Secure Shell for Windows Servers 3.1.2. 

We apologize for any inconvenience this may cause. SSH Communications
Security takes security issues very seriously and a CERT advisory,
submission to Bugtraq and notification to customers regarding this issue
have been distributed. Please make every effort to ensure that your
systems are protected using one of the above methods as quickly as
possible. As this information becomes widely known, your systems could
be at even greater risk if appropriate measures are not taken
immediately. 

SSH is Fully Committed to Serving and Supporting our Users. 

Please direct any questions you may have to the following: 

Commercial customers:
http://www.ssh.com/support/ssh/commercial_support.cfm 

Evaluating customers:
http://www.ssh.com/support/ssh/pre-sales_support.cfm 

Non-Commercial customers: 

Please note that SSH cannot promise individual responses to
non-commercial / educational users. We are fully committed to serving
and supporting our non-commercial users through web, and will make
publicly available any relevant information possible, which addresses
your questions and concerns. Please utilize non- commercial support web
pages at:
http://www.ssh.com/support/ssh/non-commercial_support.cfm 

Technical Description of the Vulnerability: 

Server configuration variable "AllowedAuthentications" can be overridden
by a client, ignoring servers' list of allowed authentication methods. 

For example if server configuration sshd2_config specifies: 

	AllowedAuthentications
		hostbased, publickey

It is possible to login using password authentication with for example
old PuTTY client versions. 

A workaround is to use "RequiredAuthentications" keyword instead of
"AllowedAuthentications" in sshd2_config: 

	RequiredAuthentications
		hostbased, publickey

This will require both hostbased and publickey authentication to succeed
before user is granted access to the system. The RequiredAuthentications
will be enforced even if the client attempts to force a disallowed
authentication method. 




 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2020, SecurityGlobal.net LLC