A vulnerability in the OpenSSH daemon (sshd) may give remote attackers a better chance of gaining access to restricted resources.
OpenSSH is an implementation of the Secure Shell protocol. It is used to provide strong authentication and cryptographically secure communications between hosts. A vulnerability in versions up to and including 3.6.1 of OpenSSH may allow a remote attacker to circumvent security policies and attempt to or actually login from IP addresses that are not permitted to access resources.
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 available 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 their possession as well as the passphrase associated with the private key.
An attacker can attempt to login to your system from a location that is not allowed. If the attacker has a private key in their possession that is allowed to access the system, they will be able to gain entry to the network. If the attacker does not have a legitimate private key, they may be able to guess a correct username/password pair if you allow password authentication.
The OpenSSH maintainers recommend enabling VerifyReverseMapping in sshd_config. You may also wish to restrict access to the secure shell service by applying packet filters for port 22/tcp at your network perimeter. While this measure will limit your exposure to attacks, blocking port 22/tcp at a network perimeter would still allow attackers within the perimeter of your network to exploit the vulnerability. It is important to understand your network's configuration and service requirements before deciding what changes are appropriate. In cases where applying packet filters is not feasible, software such as Wietse Venema's TCP Wrappers can be used to restrict access to the secure shell daemon. Finally, it is highly advisable to use public key authentication as opposed to password authentication. In our estimation, this vulnerability does not pose an imminent threat; however, it permits a greater-than-expected level of access to a security control in your infrastructure. The next release of OpenSSH will drop the VerifyReverseMapping option and, subsequently, sshd will by default perform reverse-mapping. At this point in time, we do not know if the OpenSSH maintainers plan to make a patch available before the next release.
Sun Microsystems, Inc.
VanDyke Software Inc.
Foundry Networks Inc.
SSH Communications Security
Secure Computing Corporation
Apple Computer, Inc.
Berkeley Software Design, Inc.
Cisco Systems, Inc.
F5 Networks, Inc.
Global Technology Associates
Ingrian Networks, Inc.
Internet Initiative Japan (IIJ)
Intersoft International Inc.
Juniper Networks, Inc.
MontaVista Software, Inc.
Multi-Tech Systems Inc.
Nortel Networks, Inc.
Red Hat, Inc.
Sequent Computer Systems, Inc.
Wind River Systems, Inc.
This vulnerability was discovered by Mike Harding. Note that this behavior of OpenSSH was in fact noticed and published two years earlier by Richard Silverman and Dan Barrett in "SSH, The Secure Shell: The Definitive Guide" (O'Reilly 2001, ISBN 0-596-00011-1). See section 220.127.116.11, p179 in the first edition.
This document was written by Ian A Finlay.
|Date First Published:||2003-06-06|
|Date Last Updated:||2007-01-16 20:10 UTC|