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

However you've raised some points about using SSH specifially and I'll
address those too:

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

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.

Note also that for keystroke timing to be of any use the attacker likely
has to have some inside information of events on the target system,
particularly of the exact moment when the su command was started
(allowing them to work backwards to when the password prompt was and
find that in the stream they've sniffed, etc.).

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

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

	- 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

	- 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

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

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.

> Note: you're assuming getting the root password and NOT getting the
> password of someone in the wheel group. That's the ONLY case you're
> defending against.

That's a very important case to defend against though -- especially if
the person's individual password is lost via social engineering tricks
or whatever -- since they're still partly responsible for losing it and
so long as the attacter doesn't totally destroy the audit trail you'll
know who's password was stolen.  That alone may give you a very good
lead on who the attacker is too!

> >     1. Shoulder-surf.
> 
> And if you can shoulder-surf root's password, why can't you shoulder-surf
> the person's login?

No, not usually.  Almost all the cases of shoulder-surfing I know of
directly involved the perpetrator coming up to the vicitim and asking
for some silly sysadmin task to be done.  The victim was always already
logged in.  A perp would have to be rather patient and sophisticated to
get access to both passwords.

> >     3. Bribe/blackmail/whatever someone who knows it.
> 
> And the reason that you don't get that person's password is......

because if you bribe me to give you the root password to some system
then I'm going to want a *lot* more incentive, orders of magnitude more,
to also give you my personal password.  I might not care too much about
the root password on some system, but I'm protecting my own interests in
that scenario -- I don't want to be connected in any way to what you
might do and I'm going to make damn sure you know that by increasing the
bribe threshold porportionally!  :-)

Similarly for blackmail/torture/etc. -- I'll give in to giving you the
root password much more easily than I'll give in to giving you both the
root password *and* my personal password.  (Of course any half-clued
attacker resorting to torture will realise they must use the information
they extract before the victim has a chance to warn anyone and initiate
a password change; and as a victim in that case I'd probably give them
everything I knew and then some in hopes that I'd at least live through
the incident.)

A good security officer knows this too and that's yet another reason to
require people to always use 'su' (at least when passwords are your sole
or strongest authentication mechanism).  A good security officer might
even train sys-admins in ways to trick an attacker into thinking that
the root password is all they want and is more valuable than any
personal password too!  :-)

But all of this is getting very Hollywood....

As a .sig line in a current-users posting today said:

	" Stamp out root logins .  .  .  . su "   --Bruce Anderson

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>