Vulnerability Note VU#978316

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.

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.