Back to list
OpenSSH remote clent address restriction circumvention
Jun 05 2003 12:04AM
Mike Harding (mvh welkyn com)
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)
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
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
set in an attempt to limit access to users in the internal 192.168/16
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
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.
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
Consider using tcp-wrappers to restrict access by IP address.
Consider using a packet filter or firewall in addition to the OpenSSH
This vulnerabilty was discovered by Michael V. Harding
(mvh (at) welkyn (dot) com [email concealed]) during a code inspection and verified with a DNS
[ reply ]
Copyright 2010, SecurityFocus