News

Security Advisory Regarding Vulnerability in SSH Secure Shell for Servers, SSH Secure Shell for Workstations (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 (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.

© 2002 SSH Communications Security Corp. All rights reserved. ssh® is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. All other names and marks are property of their respective owners.