[Cryptography] SSH vulnerability when using passwords
hyc at symas.com
Fri Jan 9 07:36:01 EST 2015
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
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.
> 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.
Also updated the telnetd source to reenable LINEMODE on Linux
I added LINEMODE/EXTPROC support to OpenSSH a few years back too, but
the OpenSSH developers were uninterested in merging it.
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
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
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/
More information about the cryptography