I'm afraid I'm not at all involved with OpenSSH development, so
perhaps this attack has been discussed in the past. It's something
that seems difficult to search for in mailing list archives.
I found myself reflecting on the following, mildly serious, protocol
weakness at the user-interface level. In a nutshell, the OpenSSH
client (at least as of version 1.2.2) fails to provide explicit
notification to the user that the authentication process has completed
and he or she has crossed a "trust barrier" from the local machine to
a remote machine. For example, if a user is authenticated via a key
held by "ssh-agent" or via host-based authentication through a
"hosts.equiv" or ".shosts" file, there is no indication of
successful
authentication other than a login banner.
Obviously, then, a user cannot easily distinguish a legitimate
authentication prompt presented by the local machine from a phony one
presented by a remote machine that has somehow permitted the user's
client to "silently" authenticate. Similarly, a user cannot easily
distinguish between the legitimate case of an incorrectly entered
passphrase and a phony error message and second passphrase prompt
provided by a remote machine.
What is the impact?
Well, it has always been the case that password-based authentication
to a compromised host is unsafe, at least in the sense that a
compromised OpenSSH (or original SSH) daemon can collect plaintext
passwords.
On the other hand, there is an expectation that RSA-based
authentication is safe (in the sense of keeping the passphrase
secret), even when connecting to an untrusted host. Unfortunately, a
compromised OpenSSH daemon can allow the client to authenticate without
requiring a passphrase or password, send a phony passphrase prompt to
the user, and collect the plaintext passphrase from the user.
In an ideal world, this passphrase would still be largely useless. In
practice, I don't think a passphrase is something anyone wants to give
away. For most users, it's hard to resist the temptation to use the
same (or at least a similar) passphrase for multiple private keys on
different hosts.
Also, a decoy attack like this can be launched quite easily from a
single compromised user account against its owner. If the OpenSSH
daemon on the half-compromised host is configured to permit RSA-based
host authentication via ".shosts" and ".ssh/known_hosts"
files, the
attacker can modify a few dotfiles (including creating a ".hushlogin"
file) to very effectively prompt for and store a user's plaintext
passphrase without any indication that something is seriously wrong.
There's one simple solution, of course. Have the client alert the
user when authentication completes: any authentication-related prompts
following that message are not legitimate. Ideally, the message
should be followed by a "press enter to continue" prompt (or at least
a short pause) to prevent the remote end from immediately sending
terminal control information to overwrite the authentication
completion message and circumventing the protection.
Any other thoughts?
In the meantime, I offer a simple workaround. Use "ssh-agent" or
".shosts" files preemptively; then, *any* prompts for passphrases are
immediately suspect.
Kevin <buhr at stat.wisc.edu>