Home page logo

bugtraq logo Bugtraq mailing list archives

Re: SSH & xauth
From: robert () CYRUS WATSON ORG (Robert Watson)
Date: Mon, 28 Feb 2000 21:10:06 -0500

On Mon, 28 Feb 2000, Niels Provos wrote:

This thread was about how default configurations can have negative
impact on security. You mention the CheckHostIP option in OpenSSH.
CheckHostIP defaults to 'yes'.  It introduces only additional checks
and has not influence on permitting an SSH session to proceed. Thus it
has no negative impact on your system security.

Please see below for a more detailed discussion of this issue.

I do not agree with your assumption that most SSH servers use dynamic
IP addresses.  I believe that for the majority of users the contrary
is true.  However, if you are in an environment with dynamic IP
addresses, you can turn the CheckHostIP option off.

I did not assume that most SSH servers use dynamic IP addresses--what I
did assert is that the number of servers using dynamic IP addresses will
increase due to a number of factors, not least the increased access to
broadband connectivity in the US, and the increase in use of personal UNIX
operating systems.  Many of the traditional static IP environments are
also converting to dynamic allocation due to improved ease of management,
as well as limited address space.  Our security tools should be developed
with this increasingly common environment in mind, and make use of
defaults that are appropriate for that environment.

Keep in mind also that a gradual introduction of IPv6 is occurring in a
number of frameworks--not so much in the UIS, but certainly in other less
IP-rich parts of the world.  IPv6 not only assumes renumbering, but in
fact one of the goals is to make this much easier.  In IPv4 with CIDR, as
in IPv6, the IP address has to do with packet routing, identifying
interfaces, not services on hosts.

In message <Pine.NEB.3.96L.1000225211428.18984A-100000 () fledge watson org>, Robe
rt Watson writes:
You can even imagine DNS-based spoofing causing some problems, if combined
with IP spoofing, as ssh-by-ip to a spoofed host would not generate an
unknown key warning, instead, it would connect with full trust.  This
attack is a little of a stretch on convenience for the attacker, but is
This is not true.  If you did not authorize a (canonical hostname,
public key) binding [by inserting it into OpenSSH's knownhosts file],
you will always get a warning.  Please verify your facts before you

We probably ought to take this discussion to another forum more specific
to SSH, but I'll give a brief overview of my concerns as they rally
reflect on any user-managed key type of environment--be it PGP email, SSH,

The first concern is to clearly articulate the levels of warnings
supported by SSH.  Not being intimately familar with its construction, I
have observed three types of warnings:

1) Warning, without confirmation, some administrative function has

2) Warning, with confirmation, that a new key will be introduced

3) Warning, with confirmation, that a key mismatch has been observed

When I observed that certain classes of key bindings could be instantiated
without warning the user, I meant that user confirmation was not required
to expand the scope of ``addresses'' that the key would be accepted for.
While OpenSSH does display a clear warning that it has introduced a new
key binding for the IP address of an existing Name->Key binding, it does
not request confirmation--it automatically instantiates the binding.  This
creation of a binding, without requiring user confirmation, relies on a
static relationship between names and IPs.  You claim that it introduces
no new security risks, but I see two: first, that it will introduce
spurious errors (type 3 from above) in a legitimate dynamic IP
environment.  Second, it will allow the introduction of new bindings based
on IP and DNS spoofing.

Both of these have their risks: the first set of spurious warnings reduces
sensitivity among the user community to the risks of changing keys--it may
also require users to make key administration decisions that they are not
qualified to make--either because they do not understand the issues
sufficiently, or because they do not have sufficient knowledge of the
server infrastructure to validate the correctness of the change.

The second risk may take advantage of the first issue, but does not have
to.  Imagine that users may log into services based on either a name or an
IP address, depending on their needs.  Users expect that SSH will prompt
for user confirmation during key introduction situations, and if no
confirmation is required at that time, then key validation has already
occurred.  Essentially that the known_hosts keyring reflects their
validation decisions of the past.  Using the automatic key introduction
technique, with DNS and IP spoofing, I can introduce new key bindings into
the key set that may result in this assumption being incorrect.

Suppose I pursuade a user to connect to my server by name, and they
validate the key finger print.  My key is now in their known_hosts, in a
valid way.  If I spoof DNS and IP, I can cause OpenSSH to introduce
bindings between my key and arbitrary IP addresses (assuming the IP
addresses aren't already in the file).  If the user now attempts to
connect to one of those IP addresses for a legitimate service, and spoof
IP connectinos from that IP, OpenSSH will not be in the desired situation
of prompting for new key introduction, but instead will use the existing
key without any warning.  A non-fatal advisory warning was displayed
during the attack, whereas my belief is that it should have required user
intervention as it created a new service address->key binding.

The moral of the story seems to be that key bindings should be introduced
in two situations: based on specific user confirmation of the binding
creation by providing a fingerprint, etc, or through a trusted key
introduction method such as a PKI the user has already authorized.
Automated introduction of keys in other ways may not be appropriate in
many environments, as it can generate spurious errors (key mismatches), or
can increase risk by creating the opportunity for the key management
mechanism to act in ways not parallel to the user's security assumptions.

You can postulate that the real problem here has to do with service naming
and namespaces.  The user isn't interested in the binding between
transport addresses and keys, only service names and keys.  As transport
management and service name management may be substantially different
(well-known and published allocation vs. automatic and dynamic
allocation), differences between the two namespaces should be respected.
If the user approves a key binding between a service name in one layer,
and the service, they may not be approving a binding between a name in
another layer and the service.  A comparable issue in another space would
be creating new bindings between PGP keys and alternative forms of an
address automatically.  For example, just because I have a PGP key
associated with my email address, robert () fledge watson org, doesn't mean
PGP should assume that the PGP key is appropriate for
robert () 204 156 12 50   In PGP, as I believe it should be the case in SSH,
unless a PKI is authorized to introduce new name->key bindings, bdingins
are individually authorized (web of trust, whatever).

There are also some practical management considerations.  With centralized
key files based on names, OpenSSH will replicate the central keys into
personal key files for the IP bindings.  If servers are renumbered, the
old IP->key beindigns will persist, causing spurious errors following a
renumbering of server IPs.  As address space limits becmoe more pressing,
this kind of situation will come up more frequently.

We should take further discussion offline from a bugtraq
perspective--please send replies to me and the OpenSSH mailing list.

  Robert N M Watson

robert () fledge watson org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]