On Thu, 6 Sep 2001, Curt Sampson wrote:

> On Tue, 4 Sep 2001, Bill Studenmund wrote:
>
> > If you were focusing on having a
> > log of who became root, then it is a valid arguement (and some folks in
> > this thread are).
>
> I am not. What attacks others bring up, and how this might relate (or
> might not relate) to my commit are really not under my control.
>
> Probably it would be a good idea to start a separate thread for anything
> you want to argue about that's not directly related to my commit.

But it is related as these arguements are being used as justifications for
the change in your commit. Even if you aren't doing the arguing, they are
used as justification.

> > > 1. This security measure is intended as a defense aginst people I've
> > > NOT given the password to.
> >
> > Ahhh... Ok. But how much of a defense is it? _HOW_ is it a defense?
>
> >From the commit message:
>
>     ...if you are not on a secure terminal, you must be able to
>     authenticate as a user in the "wheel" group before you may attempt
>     to authenticate as root using the root password.
>
> So the defense is that, though you have the root password, you must also
> either gain access to a secure terminal, or authenticate as a user in
> the wheel group.

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?

> > Please read the paper. It's at
> > http://paris.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf Logging into
> > a box and then doing an su is readily noticable by a passive packet
> > sniffer. Passivly watching the exchange, the snooper can get enough info
> > to reduce the difficulty of brute-force hacking by a factor of 50. That's
> > almost two orders of magnitude.
>
> I'm familiar with this. And it certainly seems to reinforce my argument
> that you want "PermitRootLogin = no" if administrative circumstances
> permit it. In fact, this kind of attack (where someone gains the root
> password) is *exactly* what I'm defending against.

WHAT? Did you READ the paper?

The point of the paper is that you can watch an ssh session and have a
good idea when someone is interactivly typing a password. Doing an su
involves an interactive password. Initiating an ssh root@foo connection
does not (since your local ssh program waits for you to finish typing the
password before sending it).

Here's a summary of the info leaks:

ssh root@foo (assuming from the machine with the keyboard): ssh v1, you
leak the password length (sent clear text). ssh v2, you leak if the
password is 8 characters or not (how many 8-character encrypted blocks get
sent).

su: either version you leak both the number of characters in the root
password AND information about what keys are being pressed (more
specifically info about where letters are located in relation to the
preceeding letter).

So how is forcing folks into the more information-leking scenario good?

> I think it's moderately obvious that having "PermitRootLogin = no"
> defends against some circumstances that "PermitRootLogin = yes" does not,
> and the converse is not true. So this is more secure.

See above about info leaking. "PermitRootLogin = yes" forces you to it.

> The failure mode where the default is "no" is that you can't log in. This
> is an obvious failure mode (if you need it to be "yes"), and easily
> remedied by the admin. The failure mode where the default is "yes" is
> that an someone (you or an attacker) with the root password can log in
> directly. If this is something you don't permit as a matter of policy,
> you may not be trying it, and thus may not notice the failure. So we've
> also picked the much more obvious failure mode.
>
> So it seems to me that we've got a much better default here.
>
> If you're not arguing that we change the default that NetBSD ships
> with, but simply that there are circumstances where a site would want
> "PermitRootLogin = yes", well, we're in perfect agreement there.
>
> > How likely is this scenario? How would such a person get the root password
> > and nothing else? Other than say using an herbivore-type program and
> > watching an su? :-)
>
> There are lots of ways to get the root password:

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.

>     1. Shoulder-surf.

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

>     2. Find or steal a written copy.

This one I can see, but it's more indicative of picking a password that
folks can't remember. Also, aren't you not supposed to write passwords
down?? :-)

>     3. Bribe/blackmail/whatever someone who knows it.

And the reason that you don't get that person's password is......

>     4. Sniff an su over ssh on a machine where "PermitRootLogins = yes"
>     (Having the option enabled doesn't stop people from running "su"!)
>     and find some way to test it out. (Even with a list of potential
>     passwords, you need some way to determine which one is the correct
>     one, and with "PermitRootLogin = no" you can't try logging in to do so.

This problem you can close by telling folks to not su. :-)

>     5. Have had it legitimately at one point, but no longer have (or
>     never have had) an account on particular machines.
>
> Certainly for situation #5, I could reel off a dozen circumstances where
> this is currently the case. (I won't, for obvious reasons.)

All the places I've been, when someone who had the root password leaves,
we change the root password. I really don't understand why you wouldn't.

Take care,

Bill