OpenSSH and keystroke timings

Knox, Bill wknox at mitre.org
Wed Sep 9 13:01:35 EST 2009


Your point 1) is a very narrow interpretation of the problem space - password entry that can be exposed happens not only during initial authentication in specific modes, but rather whenever you are prompted to enter a password (or private key passphrase). A case where entry of either of these is obvious on the network and for which this timing attack would work very nicely is as follows:

User is connected from A to B via SSH (authentication method unimportant)
User then connects within the above session from B to C and is required to enter authentication credentials (either a password or the passphrase of a private key)

In this case, an adversary watching at B from the network perspective sees the A -> B connection open. There is a then a brief spurt of activity B to C as that session is set up, followed by the prompt being written back from B to A for authentication and then the typing from A to B of the SSH passphrase or the password, each character of which is sent in its own packet (this scenario is based upon the response to the LWN article found at http://lwn.net/Articles/299112/) and which, based on an empirical test just now, is very easily discernible. Even if you can't figure out the passphrase based on timing if jitter were added (one of the ideas proposed in response to the article), or even if it is a password or a private key passphrase, you at least now know how long it is.

And to partially answer 2), even if passwords are a terribly flawed technology, they are still, along with SSH keys, what a significant number of people use, and it is potentially useful to try and overcome data leakage in SSH related to password/passphrase usage instead of discounting them as flawed authentication methods.

I'll leave giving you a hard time about your points 3) and 4) to those more knowledgeable than myself. :-)

                          Bill Knox
                          Lead Infosec Engineer/Scientist
                          The MITRE Corporation


-----Original Message-----
From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org [mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf Of Dan Kaminsky
Sent: Tuesday, September 08, 2009 6:10 PM
To: Howard Chu
Cc: openssh-unix-dev at mindrot.org
Subject: Re: OpenSSH and keystroke timings

Well, there's a lot here.  Lets go down the line.

1) Password entry only occurs during keyboard-interactive mode, which at
least isn't used by default (though it may be set on some distros).  There's
no way to downgrade someone as a MITM either.
2) Passwords in general are a terribly flawed technology, made only
palatable by the disaster that is everything else (yes, this includes
rsa/dsa in SSH).
3) Only the most basic of interactions with a server are line based.  Even
something as simple as vi requires full character mode interactivity.  Heck,
tab completion doesn't even work without it.
4) The right way to solve this class of problem isn't with LINEMODE tty,
it's with constant timing / constant bandwidth padding in the underlying
transport -- or at least, to make changes in timing and bandwidth happen a
few orders of magnitude slower than the data that's driving them.  SSH1 and
SSH2 as protocols have full support for contentless packets that contain
only padding; I'd love to see a patch.

On Tue, Sep 8, 2009 at 11:44 PM, Howard Chu <hyc at symas.com> wrote:

> Old news, but ... http://lwn.net/Articles/298833/
>
> I first posted about this back in 2001 and it's still not resolved:
> http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html
>
> 1) high latency networks are a reality that will never go away. In fact
> they will only become more prevalent since distributed networks continue to
> grow broader but (surprise) the speed of light remains a constant.
> 2) character-at-a-time protocols have both security and performance costs.
> 3) a solution for this has existed in common operating systems for a couple
> of decades already (LINEMODE tty support).
>
> It's strange how the secsh group at the IETF refused to learn from the
> lessons already gained from the years of experience with the telnet
> protocol.
> --
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


More information about the openssh-unix-dev mailing list