Vulnerability Note VU#978316

Vulnerability in OpenSSH daemon (sshd)

Original Release date: 06 Jun 2003 | Last revised: 16 Jan 2007

Overview

A vulnerability in the OpenSSH daemon (sshd) may give remote attackers a better chance of gaining access to restricted resources.

Description

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.

In addition to the methods available to authenticate a user, there also exists ways in which one can restrict access to the SSH server, such that connections are permitted only from trusted hosts. One of the most common methods is by utilizing a firewall to do host-based access restriction. Additionally, sshd has the ability to restrict access by IP address or hostname. While this is not cryptographically strong security, it provides an additional layer of protection which some sites rely upon to limit their exposure.

A flaw exists in the way OpenSSH evaluates IP addresses and hostnames. We have included an excerpt of the report sent to BugTraq regarding this vulnerability:

    Interestingly, when a purely numeric IP address is provided, an attacker who controls reverse DNS for his host can circumvent this controls by returning text containing a numeric IP address in the reverse DNS response. This would allow stolen keys containing numeric IP address restrictions to be used from other IP address, or external access to a system which had

    AllowUsers *@192.168.*.*

    set in an attempt to limit access to users in the internal 192.168/16 network.

    The exploit works because the code treats both the IP address and hostname as strings, and there is no logic to indicate when a pure IP address match should be attempted.

Impact

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.

Solution

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.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Cray Inc.Affected06 Jun 200309 Jun 2003
IBM CorporationAffected06 Jun 200319 Jun 2003
NetBSDAffected06 Jun 200309 Jun 2003
OpenSSHAffected-06 Jun 2003
Sun Microsystems, Inc.Affected06 Jun 200316 Jan 2007
VanDyke Software Inc.Affected06 Jun 200316 Jun 2003
AlcatelNot Affected06 Jun 200301 Aug 2003
ClavisterNot Affected06 Jun 200309 Jun 2003
Extreme NetworksNot Affected06 Jun 200324 Jun 2003
Foundry Networks Inc.Not Affected06 Jun 200309 Jun 2003
FujitsuNot Affected06 Jun 200316 Jul 2003
HitachiNot Affected06 Jun 200318 Jun 2003
Lotus SoftwareNot Affected06 Jun 200306 Jun 2003
MacSSHNot Affected06 Jun 200306 Jun 2003
Riverstone NetworksNot Affected06 Jun 200310 Jun 2003
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

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

References

Credit

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 5.5.2.1, p179 in the first edition.

This document was written by Ian A Finlay.

Other Information

  • CVE IDs: CVE-2003-0386
  • Date Public: 04 Jun 2003
  • Date First Published: 06 Jun 2003
  • Date Last Updated: 16 Jan 2007
  • Severity Metric: 37.13
  • Document Revision: 38

Feedback

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