--6sX45UoQRIJXqkqR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005.08.26 11:44:27 +0000, Bill Studenmund wrote:
| On Fri, Aug 26, 2005 at 07:46:44PM +0100, Rui Paulo wrote:
| > On 2005.08.26 10:24:31 +0000, Bill Studenmund wrote:
| > | On Thu, Aug 25, 2005 at 01:26:29PM +0100, Rui Paulo wrote:
| > | >=20
| > | > This is not a security issue from my POV. What I want is an option =
to
| > | > change the behaviour. That's all.
| > |=20
| > | It is. It means that you can remotely attempt to crack the root passw=
ord=20
| > | by throwing a dictionary attack at login; the different messages will=
=20
| > | indicate when you got the right password.
| >=20
| > I was refering to the "root login not allowed on this terminal" message=
s.
|=20
| As am I. As is Zafer.
|=20
| They leak security information. And that is bad.
|=20
| Say I am a remote attacker trying to log in directly as root. I'm logging=
=20
| in via an insecure terminal, so I have no chance of actually getting in.=
=20
| And yes, there will be "root login attempt" messages & such in the local=
=20
| logs.
|=20
| However, and this is the sticky point, I, as a remote attacker, will get
| one message thrown at me if I get the password right and a different
| message thrown at me if I get it wrong. So even though I didn't get in
| (and had no chance of getting in), I know if I got the root password
| right. Thus I can use a remote dictionary attack to figure out the root
| password; I just keep going until I get a different reject message.
|=20
| There are a number of ways of fixing this.
|=20
| Probably the best is to consolidate them, and make one "You can't get in=
=20
| because either this terminal is insecure or you typed in the wrong=20
| password" message. I know there was a patch mentioned in this thread, it=
=20
| should get added to the PR. I don't know if that's what the patch does...

I don't object to such a change, of course, but I was wondering if we could
add a variable (to login.conf maybe?) that defines the behaviour the system
administrator wants.

Wether to enable or disable that variable by default, should be discussed
on tech-security, I suppose.

But anyway, if this is something problmatic for most systems we should
print a "Login failed" message then. Nowdays most people are using SSH for
authentication and they don't suffer this problem.

		-- Rui Paulo

--6sX45UoQRIJXqkqR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDD8p5ZPqyxs9FH4QRAjjPAKC0DIj/Rm9G+YgiVWHT35B1gkg2OgCfYE9H
b8Hymo4EX8G1vxodjbEP3/8=
=BMsI
-----END PGP SIGNATURE-----

--6sX45UoQRIJXqkqR--