On Wed, 5 Sep 2001, Sean Doran wrote:

> | With direct root logins, the only thing which gets leaked is if the password
> | has eight characters or not.
>
> Well, just as an aside, there are lots of exceptions to both these
> assertions.  The one that motivated the reply is that a snooper must
> first know that the snooped party is actually running su, which is
> somewhat hard in the case where only 1/2 the traffic is being seen.
> (It's easier if you see three minimal-data packets a return larger
> packet ("Password:" is great known cleartext), and then some number of
> minimal-sized packets with only ACKs, and with a larger data packet
> ("...# ", with the last two being great known cleartext, and you can
> also make some assumptions about "...") after the string of ACKs.
> In a "log in and immediately su" transaction, this is much easier
> to identify, even without seeing both directions.

Right. The paper focused most of its efforts on cases where you could see
all the traffic. You get the timing from one side (the key presses to su)
and the fact it's an su from the lack of echos on the other side.

Please read the paper. I would appreciate comments from the points in the
paper, but the commenters will really have to have read it first. :-)

> Direct root logins have the advantage to the attacker that the
> very first exchange is going to have some known cleartext, and
> the first obviously-interactive set of keystrokes are almost
> certainly the password, against which one can play all sorts of
> timing analyses which may or may not help sort the order of brute-force
> attacking to achieve a reduction in mean-time-to-crack.

Uhm, my understanding is that if I am logged in to a local shell (say in
an xterm) and type ssh host, the password keypresses are aggregated into
one packet - the local ssh waits until I finish the password, and sends it
all at once. Thus if I ssh root@host, the password is sent as a whole.
Thus there isn't the interactive traffic you mention.

> When you can discover an "su" in progress, which is the additonal
> hard part, you have exactly the same problem to sort out as a
> direct root login, where a password is required.

See above. I think one of the main points is that su will show timing
delays, while direct root won't. I'm basing that on my read of the paper,
so I could well be wrong. :-)

> "Chaff" and artificial delay (even beyond Nagle) significantly
> strips away useful sorting information in either case.

The paper talks about this.

> Public-Key direct root logins are even better, although one
> can look for the enter-unlock-code dialogue if it happens across
> a network (e.g., recursive ssh (ssh hosta ssh hostb command)).
>
> Finger travel time analyses are less spooky when one considers
> the amount of noise introduced through ordinay routing equipment.
> Even on LANs, any kind of transmit delay (other traffic) will
> strip out timing information, as will the poor resolutions (4ms+)
> one gets when timing packet arrival times on many platforms.

The paper concentrated on breaking things into bins which were like 50ms
or 100 ms wide. So 4ms resolution is fine for this kind of attack.

> However, a long-term sniffer which is not defeated by chaff or
> constant queueing noise, can probably make pretty good guesses
> at what's being typed, especially if virtually every keystroke is
> in its own packet.  (i.e., people don't suddenly improve or disimprove
> wrt how they type, touch typists tend to be pretty consistent
> according to qwerty theory, and that kind of thing).

The paper talks about this. :-)

> Again, the answer here is not so much handwringing about
> whether to allow root login or whatever, but rather what
> to do about the fact that timing analyses are probably
> useful in attacking encrypted interactive data streams,
> be they ssh or ipsec or kerberos, especially where
> there is some degree of known plaintext at the start of
> such a stream, or any other absolutely predictable moment.

Note the point I mentioned above - with a direct root login, the only info
leaked is the password length (ssh 1 sends it in the clear, with ssh 2 I
gather you can figyre out if its an 8 char password or not) since the
password is sent all at once, while with su you get length and timing
info. So there is a difference. If the password were sent interactivly
with a direct login, then yes, it wouldn't make a difference.

Take care,

Bill