[Cryptography] SSH vulnerability when using passwords

[Nico Williams]

On Tue, Jan 06, 2015 at 03:42:05PM -0800, John Gilmore wrote:
> But neither that nor the ssh wikipedia page mention an SSH
> vulnerability that lets an attacker guess the letters of a remote
> login password used under SSH.  I remember this attack being mentioned
> years ago, perhaps in a crypto conference rump session?
> 
> The attack works when you don't use keys or shared secrets -- just the
> usual login/password processing standard for the remote end's
> operating system.  [...]
> 
> The problem is that the ssh protocol sends each letter of the password
> as an entire packet of encrypted stuff -- but there are only a small
> number of possible letters that might have been typed.  So the entropy
> in each of those early ssh packets is very low.  [...]

When SSH itself is being used to login with a password, then this is not
so (in all the SSHv2 userauth cases a whole password is sent in one go,
not one character at a time, interactively).

But when one runs, say, "sudo" or some other application that turns off
tty echo and reads a password from the tty, then the other end of the
tty (whether it's SSH or something else) generally doesn't know this and
feeds characters as they are typed.  If an attacker knows that the user
is doing this then they can glean some information from timing of
packets.

Propagating echo on/off (and cooked/raw) mode backwards from the tty all
the way to the first client is the correct answer, IMO.  Failing that,
mosh-style heuristics / output prediction should help the client detect
that the tty is in echo off (and cooked or otherwise line-oriented)
mode, so that the client nearest the real TTY (terminal emulator,
really) can read a whole line before sending anything.

I ought to know if it's possible for pty masters to tell what mode the
other side of the pty is in, but all I can recall (and a brief search)
is that the master doesn't get messages about such changes, though it
can poll the pts.  One would think that TIOCPKT mode would have
supported this, but evidently not...  (caveat emptor: brief reply,
little research).

Nico
--