Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Linux :: Apps N-Z :: bt358.txt

OpenSSH remote clent address restriction circumvention





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.





TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH