This advisory demonstrates several weaknesses in implementations of
SSH (Secure Shell) protocols. When exploited, they let the attacker
obtain sensitive information by passively monitoring encrypted SSH
sessions. The information can later be used to speed up brute-force
attacks on passwords, including the initial login password and other
passwords appearing in interactive SSH sessions, such as those used
with su(1) and Cisco IOS "enable" passwords.

All attacks described in this advisory require the ability to monitor
(sniff) network traffic between one or more SSH servers and clients.

Fix information, patches to reduce the impact of traffic analysis, and
a tool to demonstrate the attacks are provided.

Impact
------

Version 1 of the SSH protocol, unless its implementation takes special
precautions to avoid this, exposes the exact lengths of login
passwords used with password authentication. The SSH-2 protocol
doesn't reveal as much information, but a range of possible password
lengths can still be determined.

Additional weaknesses make it possible to detect when a password is
entered during an interactive SSH session, and to discover even more
information about such passwords, including their exact lengths (with
both protocol versions) and timing information. The latter exposes
the likelihood of possible characters in each position of a password.

All this information may be entered into a brute-force password
cracker for a significant speedup due to reduced keyspace and other
optimizations, including attacking user passwords in the order of
increasing estimated complexity.

Additionally, our SSH traffic analysis tool is able to detect the use
of RSA or DSA authentication, and in the case of RSA and SSH 1.2.x
derived SSH server implementations, the number of authorized_keys
file options. The latter is possible due to debugging packets sent
by those implementations. If a SSH session with RSA authentication
but no authorized_keys options is seen, an attacker may infer that
the client machine has the private key sufficient to obtain full
shell access to the server. If the session is automated, the private
key has to be stored unencrypted.

Finally, it is possible to determine the lengths of shell commands,
and in some cases, the commands themselves (from a small list of
common ones) in an interactive session (which isn't a security issue
under most circumstances).

It should be noted that, despite their simplicity, traffic analysis
attacks such as those presented in this advisory haven't been well
researched. We expect that similar attacks are possible against most
other "secure" (encrypted) remote login protocols. We also expect
additional traffic analysis attacks on SSH to be discovered. In
particular, there may be recognizable patterns in X11 connections
forwarded over SSH, but these are out of the scope of this advisory.

When encapsulating plaintext data in a SSH protocol packet, the data
is padded to the next 8-byte boundary (or whatever the cipher's block
size is, with SSH-2), encrypted, and sent along with the plaintext
length field. SSH-1 sends this field in the clear.

As a result, an attacker passively monitoring a SSH session is able
to detect the amount of plaintext sent in each packet -- exact for
SSH-1, or a range of possible lengths for SSH-2.

Since the login password is sent in one SSH-1 protocol packet without
any special precautions, an attacker can determine the exact password
length.

With SSH-2, other information (including the username) is transmitted
in the same packet and the plaintext length is encrypted, so only a
range of possible password lengths can be determined.

Fortunately, due to the use of C strings in most SSH-1 server
implementations, it is usually possible for a SSH client to add
sufficient NUL padding for just the passwords without a change to the
protocol. We recommend that future SSH-1 server implementations allow
for this padding, even in cases where the underlying OS interfaces do
not necessarily imply this.

An alternative workaround, proposed by Simon Tatham, is to send a
sequence of SSH-1 messages containing strings of increasing length.
Exactly one of these messages is SSH_MSG_PASSWORD and contains the
password string. All the rest are SSH_MSG_IGNORE. It is important
that the number of messages sent remains constant and is sufficient
to cover the longest password we expect to see. To safely transmit
passwords of up to 32 characters, 1088 bytes of SSH-1 messages are
needed, which may still fit within one TCP segment. This approach has
the advantage that no assumption about SSH-1 server implementations is
made (other than that they implement the protocol correctly; some
implementations are known to have problems handling SSH_MSG_IGNORE).

The SSH-2 protocol allows for a solution (independently proposed by
several SSH-2 implementation authors) with less overhead, and without
reliance on artifacts of protocol implementation. A pair of SSH-2
messages, SSH_MSG_USERAUTH_REQUEST and SSH_MSG_IGNORE, may be
constructed such that their combined length remains constant. The
messages can then be sent to the transport layer at once.

Interactive session weaknesses
------------------------------

With interactive shell sessions, input characters are normally echoed
by the remote end, which usually results in an echo packet from the
server for each input character. However, if an application turns
input echoing off, such as for entering a password, the packets start
to go in one direction only -- to the server. Our simple traffic
analysis tool is able to detect this easily and reliably.

Once an attacker knows that the victim is entering a password, all
they need to do is count the packets that didn't generate a reply
packet from the server. In the case of SSH-1, the sum of plaintext
sizes gives the exact password length, save any backspace characters.
With SSH-2, the attacker has to assume that each packet contains only
one password character, which is typically the case.

The delays between packets give the attacker additional information
on the likelihood of possible characters in each position of the
password. For example, if the delay before a character is larger than
most other delays, it is likely that the character requires more than
one keystroke to type.

When typing commands in a command-line shell over SSH, each character
generates a tiny echo packet from the server. However, once the
entire command is entered, a larger packet -- containing the shell
prompt and possibly the command's output -- is sent by the server.

By counting the tiny packets (or the plaintext lengths in packets
sent to the server, in the case of SSH-1), the attacker can infer
the length of each shell command. To make detection more reliable
with SSH-1, it is usually possible to detect backspaces by assuming
that they produce a 3-character response (^H, space, ^H).

Once again, the delays may be used -- this time for inferring the
actual shell commands typed, from a small list of common ones.

The partial solution we propose is to modify SSH servers such that
they simulate echo packets when terminal echo is disabled by an
application. The SSH_MSG_IGNORE message type may be used to ensure
the client doesn't actually process the contents of these fake packets.
Thus, no change to the protocol is required.

It is important to note that this partial solution may only defeat
the most generic way to infer that a password is entered. In many
cases it is possible to do the same by other means, including
monitoring other related network traffic and events local to a SSH
server system.

Solving traffic analysis vulnerabilities not related to password
information would increase the protocol overhead significantly, and
thus doesn't seem practical for many current uses of SSH.

Compression
-----------

The use of compression makes many of the traffic analysis attacks
described above significantly less reliable. This is because the
same amount of plaintext no longer results in the same amount of data
being transmitted. The packet sizes are somewhat "randomized".

However, it is likely that compression also enables yet another class
of traffic analysis attacks, as the changes to packet size due to
compression aren't actually random -- they depend on the plaintext
packet contents.

We're already aware of one practical attack that is possible due to
compression. With SSH-2, the SSH_MSG_USERAUTH_REQUEST message is
transmitted after compression is negotiated. If enabled, the size of
the resulting TCP segment will depend on the entropy of the plaintext
password. If a SSH_MSG_IGNORE message is used to pad the password as
we have proposed, compression may defeat some of the benefit this
could have provided. This instance of the problem may be solved by
transmitting the SSH_MSG_USERAUTH_REQUEST and SSH_MSG_IGNORE messages
uncompressed. However, this is non-trivial to implement if a generic
compression library is used.

Related work
------------

Several of the attacks outlined in this advisory were also
independently discovered by the authors of the following paper (still
work-in-progress), which describes some of them in greater detail:

In particular, they reveal that inter-keystroke timings leak about 1
bit of information per character pair, and describe an attacking
system, Herbivore, which tries to learn users' passwords by
monitoring SSH sessions. Herbivore is demonstrated to reduce the
search space for uniformly randomly chosen passwords of 8 characters
by a factor of 50.

Although the paper is not yet publicly available, vendors working to
fix these problems may contact David Wagner <daw at cs.berkeley.edu>
or Dawn Xiaodong Song <dawnsong at cs.berkeley.edu> to obtain a copy.

Fixes
-----

Several SSH implementations have been changed to include fixes which
reduce the impact of some of the traffic analysis attacks described
in this advisory. It is important to understand that these fixes are
by no means a complete solution to traffic analysis -- only simple
remediation for the most pressing vulnerabilities described above.

OpenSSH:

Fixes have been initially applied to OpenSSH starting with version
2.5.0. OpenSSH 2.5.2 contains the more complete versions of the
fixes and solves certain interoperability issues associated with the
earlier versions.

PuTTY:

PuTTY 0.52 will include defenses against inferring length or entropy
of initial login passwords, for both SSH-1 and SSH-2.

SSH 1.2.x:

SSH 1.2.x users can use this unofficial patch (the patch is against
version 1.2.27, but applies to 1.2.31 as well). Please note that a
SSH server with this patch applied will not interoperate with client
versions 1.2.18 through 1.2.22 (inclusive).

We have developed a SSH traffic analysis tool, which can be used to
demonstrate many of the weaknesses described in this advisory. The
source for initial version of the tool is included below. Future
versions will be maintained as a part of Dug Song's dsniff package,
available at:

<++> sshow.c
/*
* SSHOW.
*
* Copyright (c) 2000-2001 Solar Designer <solaropenwall.com>
* Copyright (c) 2000 Dug Song <dugsongmonkey.org>
*
* You're allowed to do whatever you like with this software (including
* re-distribution in source and/or binary form, with or without
* modification), provided that credit is given where it is due and any
* modified versions are marked as such. There's absolutely no warranty.
*
* Note that you don't have to re-distribute modified versions of this
* software under these same relaxed terms. In particular, you're free to
* place them under (L)GPL, thus disallowing re-distribution of further
* modifications in binary-only form.
*/

/*
* Some of the checks may want to skip over multiple server responses.
* For example, there's a debugging packet sent for every option found
* in authorized_keys, but we can't use those packets in our pattern.
*/
skip = 0;
while (((session->history.directions >> skip) & 3) == 3)
if (++skip > HISTORY_SIZE - 5) break;

This advisory, the SSHOW traffic analysis tool, and the unofficial
SSH 1.2.x patch were written by Solar Designer <solaropenwall.com>
and Dug Song <dugsongmonkey.org>. We would like to thank the SSH
implementation authors, especially Markus Friedl and Theo de Raadt
(of OpenSSH), Simon Tatham (PuTTY), and Niels Möller (LSH) for
improving on our initial SSH traffic analysis countermeasures. We
would also like to thank David Wagner and Dawn Xiaodong Song at the
University of California, Berkeley and Ariel Futoransky of CORE-SDI
for insightful discussions.

Updated versions of this and other Openwall advisories will be made
available at: