On Thu, 6 Sep 2001, Greg A. Woods wrote:

> [ On Thursday, September 6, 2001 at 13:03:44 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: sshd Change: PermitRootLogin = no
> >
> > The whole point I'm arguing, is *why* is this important? *Why* do you
> > think this is a more likely an attack than the attack modes opened up by
> > this change?
>
> Bill, w.r.t. to changing the default PermitRootlogin setting this really
> has nothing whatsoever to do with SSH specifically -- it's only really
> related to how you identify the real-world user requesting super-user

Greg, please read Curt's messages. You and he are arguing for this change
using different reasons. Thus I argue different points to each of you. :-)

> privileges.  The same issue occurs regardless of what session protection
> mechanism is used (even when the mechanism is an external physical
> security measure, such as a secure hard-wired terminal).

> > So how is forcing folks into the more information-leking scenario good?
>
> If I'm not mistaken critiques of the paper you've referred to have
> already tried to show there's very little leakage of keystroke timing if
> there's more than one or two hops in the SSH circuit.

I haven't seen those comments. But the paper used a rather coarse binning
of timing - like 50ms or 100ms. So unless the hops had a LOT of
variablilty, I think the binning would still work. But that's a blind
guess.

It would be ironic if having a crappy network connection made things
safer.

> One thing I haven't seen discussed is whether or not such keystroke
> timing information is generic enough to produce useful results when the
> typing style of the victim is not known.....  I suspect it is not, but
> I'm not a statistics or human-factors expert on these matters.....
>
> I.e. all in-all the specific scenario where useful keystroke timing is
> potentially available is quite rare in practice.

This point was discussed in the paper. You don't need the exact keystroke
info of the user - info for someone who types similarly will work well. So
all an attacker needs is a few profiles, and a way to guess which profile
works best for a person. I'll be honest I'm not sure of a good way to
align profiles, but I bet you can make guesses from watching the ssh
stream.

> So, in the end if "PremitRootLogin=NO" a successful attack requires:
>
> 	- the ability to sniff the SSH data stream at a point where the
>           keystroke timing is likely still useful

Not sure how hard this is. See above.

> 	- the ability to run the analysis to narrow the root password
> 	  domain down to a size where a brute-force attack is feasible

That's a savy programmer, but as root kits show, that doesn't mean a savy
attacker. :-(

> 	- the ability to detect the exact moment when an su command is
> 	  started so that the appropriate part of the SSH data stream
> 	  can be found for the above analysis

As smb said, "easy".

> 	- the ability to gain shell-level access to the target system
> 	  under the ID of a wheel-group member, which almost certainly
> 	  means obtaining their personal password too, or maybe even
> 	  using several hops and exploits to get there

Not sure how hard this is.

> 	- the ability to run enough 'su' commands undetected to brute-
> 	  force the remaining unknown bits of the root password

Not sure how hard this is. I'd have expected a brute-force attack, either
via su or trying to directly bruit-force the root password would be
noticable.

> that's a *lot* of deterrent!
>
> However with "PermitRootLogin=YES" the attacker has many more avenues of
> attack and fewer risks to themselves of detection during the attack
> process since no wheel-group shell-level access is required and all
> parts of the attack can take place from perhaps any arbitrary remote
> location (or at least from any network any authorised root user can
> connect from).  All the attacker needs to learn is the root password
> itself.

Either the admins are playing loosie-goosie with passwords or they aren't.
If they are playing loosie-goosie, then you have real troubles. If they
aren't, then you still have a password to bruite-force in there somewhere,
which I'd expect to be noticed.

Take care,

Bill