Re: Ssh security hole?

[Tatu Ylonen <ylo@cs.hut.fi>]

(I'll forward your message to a couple of lists where it might be
of interest; the original message is at end.)

I think you are right in your analysis.  There is indeed a problem
with RSA authentication.  Basically what this means is that if you log
into a corrupt host, that host can at the same time log into another
host with your account (by fooling you to answer to the request)
provided that you use the same RSA identity for both hosts.

A workaround is to use a different identity for each host you use.
The default identity can be specified on a per-host basis in the
configuration file, or by -i options.

And, yes, I think the same problem might occur with client host
authentication.  Though, there you would still have to do IP-spoofing,
DNS spoofing or similar to get through (breaking RSA based host client
effectively reduces RhostsRSAAuthentication to conventional .rhosts
authentication).

The protocol will need to be changed somewhat because of this.  I'll
think about it tomorrow and let you say you opinion about it.

Thanks!

    Tatu Ylonen <ylo@cs.hut.fi>

Date: Thu, 13 Jul 1995 13:08:15 -0700
From: David Mazieres <mazieres@pa.dec.com>
To: ssh-bugs@cs.hut.fi
Cc: rtm@eecs.harvard.edu, dm@eecs.harvard.edu, tbl@eecs.harvard.edu
Subject: Ssh security hole?

I believe there is a serious problem with the RSA authentication
scheeme used in ssh, but then again I could be misreading the proposed
RFC.  Is the following really the case?

As I understand the protocol, here is what happens during SSH_AUTH_RSA
authentication.

Suppose the holder of SKu, is allowed access to account U on machine B
(which holds SKb).  Both PKu and PKb are widely known.  In addition,
machine B has a session key, PKs, which changes every hour.  When U on
machine A wants to log into machine B, here's what I think happens
based on my reading of the RFC:

A -> B: A

B -> A: (PKb, PKs, COOKIE)
	[A flags an error if PKb is not the stored value.]

A -> B: (COOKIE, {{Kab}_PKs}_PKb)
A -> B: {U}_Kab
A -> B: {PKu}_Kab
	[B aborts if SKu is not allowed access to account U.]

B -> A: {{N}_PKu}_Kab

A -> B: {{N}_MD5}_Kab (*)
	[B aborts if the MD5 hash is invalid.]

B -> A: access to acount U with all data encrypted by Kab.

The problem is, suppose U actually wanted to log into machine C, which
was maintained by an untrusted person.  The person maintaining C could
initiate a connection to B the minute U tried to log into C.  When
given a challenge {{N}_PKu}_Kbc, C could simply give this to A as the
challenge to respond to, and then forward the response to B.

To fix the problem, A must at the very least include B in the
response line marked (*).  I have reason to believe (after having just
seen a lecture on authentication), that you might even need to include
more.  A safe bet might be (but then again I am no expert):

A -> B: {(N, A, B, Kab)}_MD5

I think similar problems arise for the other authentication methods.

Other than that, though, I am really impressed by by ssh.  It's easy
to install and easy to use.  In fact, it is even more convenient to
use than standard rsh, because the X forwarding happens
automatically.

Thanks for such a great package!

David