Welkyn Security Advisory SA-2003060400 Synopsis: SSH "from=" and "user@hosts" restrictions spoofable via reverse DNS for numerically specified IP addresses. Issue Date: June 4, 2003 Software Affected: OpenSSH 3.6.1 and earlier Vendor notified: May 24, 2003. Vendor response: See workarounds, below. Severity: Low/Medium (unauthorized remote access) Description: OpenSSH provides a number of mechanisms to restrict client remote logons to a server. An individual user may use "From=<hostpattern>" in their $HOME/.ssh/authorized_keys file, the sshd_config file can use '<userpattern>@<hostpattern>' to restrict certain users to logging in from certain hosts. The hostpatterns are similar to Unix glob file matching, with ? and * acting as wildcards. Either an IP address or a host name may be specified in the pattern. When a host name is specified, a reverse lookup is done on the IP address of the client host. Trivially, this is spoofable when the attacker controls his own reverse DNS. The sshd_config file for the server does provide a VeriftyReverseMapping flag (which defaults to 'no') that will cause a reverse DNS lookup to be followed by a forward DNS lookup and the two mappings will be required to match, preventing trivial spoofing. 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. This exploit does not provide direct access to server, but may allow access from disallowed hosts. An example could be a former employee who has a password or private key but no longer has access to the network from inside the company, or an external hacker who is guessing passwords. The commercial F-Secure SSH-1 and SSH2 products do not appear to have this problem - they must have been fixed after the OpenSSH code fork. Workarounds: Enable 'VerifyReverseMapping' on the sshd server - this may, however, lead to slow logins when the client doesn't have a reverse DNS server. This is the vendor recommended workaround. Future versions of OpenSSH should address this vulnerability, either by documentation or code changes. Consider using tcp-wrappers to restrict access by IP address. Consider using a packet filter or firewall in addition to the OpenSSH restrictions. Contact: This vulnerabilty was discovered by Michael V. Harding (mvh@welkyn.com) during a code inspection and verified with a DNS server.
