bugtraq - OpenSSH remote clent address restriction circumvention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1054771465.4325.4.camel@netcom1.netcom.com>
Date: 04 Jun 2003 17:04:25 -0700
From: Mike Harding <mvh@...kyn.com>
To: bugtraq@...urityfocus.com
Subject: OpenSSH remote clent address restriction circumvention

Welkyn Security Advisory SA-2003060400

Synopsis: SSH "from=" and "user@...ts" 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 *@....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@...kyn.com) during a code inspection and verified with a DNS
server.