[Cryptography] SSH vulnerability when using passwords

[Howard Chu]

Jumping in here...

> 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.

This is all pretty old hat. It was a common attack against S/Key too, 
back in the day. http://www.cultdeadcow.com/cDc_files/cDc-0327.txt But 
it was also easy to mitigate, using Telnet LINEMODE.
https://tools.ietf.org/html/rfc1184



> 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).

The Linux kernel originally supported this all no problem, by virtue of 
the EXTPROC tty setting, which it inherited from BSD's tty driver. 
Somewhere along the line some numbskull deleted EXTPROC support from the 
Linux tty driver. I added it back a few years ago.
https://lkml.org/lkml/2010/6/11/132

Also updated the telnetd source to reenable LINEMODE on Linux
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585527

I added LINEMODE/EXTPROC support to OpenSSH a few years back too, but 
the OpenSSH developers were uninterested in merging it.
https://github.com/hyc/OpenSSH-LINEMODE

These days, with even CLI-based systems tending to use 
CBREAK/character-at-a-time input even for line-oriented input, more work 
needs to be done. E.g., for Bash's TAB/command-completion, which uses 
libreadline.
http://lists.gnu.org/archive/html/bug-bash/2010-06/msg00059.html

I also have a patch for tcsh lying around somewhere. The OpenSSH guys 
wanted to see BSD libedit supported instead of GNU libreadline; I got 
part way into that but never finished. Too much of an uphill battle 
trying to convince ignorant developers of why it's an important feature 
to support.

FWIW, bash works fine with the last OpenSSH revision I patched.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/