NetBSD Problem Report #4417

Received: (qmail 11646 invoked from network); 3 Nov 1997 03:34:50 -0000
Message-Id: <199711030335.TAA01106@nooksack.ldc.cs.wwu.edu>
Date: Sun, 2 Nov 1997 19:35:58 -0800 (PST)
From: Scott.Burns@Netcontech.Com
To: gnats-bugs@gnats.netbsd.org
Subject: s/key implementation reveals existance of valid account names without S/Key
X-Send-Pr-Version: www-1.0

>Number:         4417
>Category:       security
>Synopsis:       s/key implementation reveals existance of valid account names without S/Key
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    security-officer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 02 19:50:01 +0000 1997
>Closed-Date:    Fri Jan 28 22:34:22 +0000 2000
>Last-Modified:  Fri Jan 28 22:39:21 +0000 2000
>Originator:     Scott Burns
>Release:        NetBSD/i386 V1.2.1
>Organization:
NETCON Technologies Inc.
>Environment:
NetBSD ncti40.ncti.com 1.2.1 NetBSD 1.2.1 (NCTI40) #0: Fri Apr 25 16:49:40 PDT 1
997     root@ncti40.ncti.com:/usr/src/sys/arch/i386/compile/NCTI40 i386


>Description:

>How-To-Repeat:
(Originally sent to tech-security as a plain e-mail as I had no send-pr
access at the time.)

In attempting to bring up s/key on a few key accounts on a machine
this weekend I ran into something I feel weakens it’s effectiveness
under NetBSD.

If I setup say the "root" account to have s/key, and another account
called jsmith does not have s/key, the following takes place:

telnet localhost

Login: nonuser
Password: s/key
Login incorrect

telnet localhost

Login: jsmith
Password: s/key
You have no s/key. Login incorrect

This now reveals to me that account jsmith is a valid account on this
machine, and does not use s/key, so I can begin to hack. Should this
extra message be removed ?

Or as mailed to me by angelos@dsl.cis.upenn.edu maybe:

I suppose the correct behaviour is to offer a bogus
challenge if the user is nonexistant or not setup for s/key (makes
debugging a bit more difficult).

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->security-officer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Thu Jan 14 01:03:41 PST 1999 
Responsible-Changed-Why:  
This PR is the responsibility of the NetBSD Security Officer, 
not the GNATS database administrator. 
State-Changed-From-To: open->analyzed 
State-Changed-By: fair 
State-Changed-When: Mon Mar 15 21:52:29 PST 1999 
State-Changed-Why:  
In the modern age, it's very difficult to keep the user list of a host 
completely confidential, and I have to wonder if it's worthwhile. With 
this information, an attacker now has an account that he can try passwords 
against, or annoy with spam, or attempt to fill up /var/mail.... 

In the end, however, all these attacks reveal themselves to even a lazy 
system administrator. Is this additional atempt to raise the bar for 
a potential system attacker really worth the effort? 

From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
To: gnats-bugs@netbsd.org
Cc: fair@netbsd.org
Subject: security/4417
Date: Wed, 6 Oct 1999 11:08:58 +0200

 If the 2nd option (creating a fake challenge) is easy to implement, it 
 should be done.

 Until then, the 1st option (at least to explictly admitting that there
 is an activated s/key on this system) should be done.

 We should not make data collection easier than it used to be on ancient BSD...

 Regards,
 	-is

From: "Martin J. Laubach" <mjl@emsi.priv.at>
To: gnats-bugs@netbsd.org
Cc: fair@netbsd.org, is@netbsd.org
Subject: security/4417
Date: Sat, 30 Oct 1999 02:41:07 +0200

   Meanwhile (1.4 and later) everything has changed:

 	login: mjl
 	Password [s/key 658 hedg29176]:

   while entering s/key at the password prompt will yield
 "login incorrect", no matter whether the user exists, or
 has s/key enabled.

   What now?

 	mjl


From: Ignatios Souvatzis <is@jocelyn.rhein.de>
To: "Martin J. Laubach" <mjl@emsi.priv.at>
Cc: gnats-bugs@netbsd.org, fair@netbsd.org, is@netbsd.org
Subject: Re: security/4417
Date: Sat, 30 Oct 1999 13:15:19 +0200

 On Sat, Oct 30, 1999 at 02:41:07AM +0200, Martin J. Laubach wrote:
 >   Meanwhile (1.4 and later) everything has changed:
 > 
 > 	login: mjl
 > 	Password [s/key 658 hedg29176]:
 > 
 >   while entering s/key at the password prompt will yield
 > "login incorrect", no matter whether the user exists, or
 > has s/key enabled.
 > 
 >   What now?

 That's even worse than before. OTOH, on a s/key enabled system, non-s/key
 users or rather, non-existent users could get a fake challenge, maybe?
 	-is

From: "Erik E. Fair" <fair@clock.org>
To: gnats-bugs@netbsd.org
Cc: Ignatios Souvatzis <is@netbsd.org>, "Martin J. Laubach" <mjl@netbsd.org>
Subject: Re: security/4417
Date: Wed, 26 Jan 2000 15:56:36 -0800

 OK, let me see if I have this problem figured out:

 1. we don't want to reveal any information about who has an account, 
 and who doesn't because that might help an attacker. Never mind that 
 such information from a multi-user UNIX system is routinely revealed 
 by other mechanisms (e.g. E-mail, IRC, identd, finger).

 2. Given #1, and a system with S/Key One Time Passwords enabled, the 
 fact of a user getting an S/Key prompt reveals that the user exists 
 and has an S/Key password. However, a valid user without an S/Key and 
 an invalid user (who, by definition, has no S/Key) are both greeted 
 by the standard "Password:" prompt.

 3. Therefore, we want to issue a bogus challenge, IFF S/Key is 
 enabled on the system for any users when we are presented with an 
 invalid username?

 Of course, if we do that, then the attacker can determine through 
 trial which users are valid, but do not have an S/Key.

 I think the status quo is fine. The users with the weakest 
 authentication mechanism are still hidden, at the expense of exposing 
 the users with a stronger authentication mechanism.

 I see no way to win (i.e. reveal no information) here, unless *all* 
 users have S/Keys, and I see no mechanism to test that (MxN password 
 file versus /etc/skeykeys file comparison every time someone tries to 
 login? I don't think that's such a hot idea).

 	Erik E. Fair <security-officer@netbsd.org>
State-Changed-From-To: analyzed->closed 
State-Changed-By: fair 
State-Changed-When: Fri Jan 28 14:34:22 PST 2000 
State-Changed-Why:  
Examination of the login.c source code and some thinking about the 
information revelation possibilities (and their mitigation) leads the 
Security Officer to close this PR leaving things status quo (which has 
changed since the PR was submitted) because there's no way to really win 
here - the question is simply who you screw and how because you must 
prompt S/Key users and non-S/Key users differently, and that reveals 
information. 

From: "Martin J. Laubach" <mjl@emsi.priv.at>
To: "Erik E. Fair" <fair@clock.org>
Cc: gnats-bugs@netbsd.org, Ignatios Souvatzis <is@netbsd.org>,
        "Martin J. Laubach" <mjl@netbsd.org>
Subject: Re: security/4417
Date: Sat, 5 Feb 2000 03:39:44 +0100

 | 1. we don't want to reveal any information about who has an account, 
 | and who doesn't because that might help an attacker. 

   We also do not want to give out information who has s/key
 login enabled.

 | 3. Therefore, we want to issue a bogus challenge, IFF S/Key is 
 | enabled on the system for any users when we are presented with an 
 | invalid username?

   No, if s/key is enabled, one would rather want to present _all_
 users -- no matter if (a) valid, no s/key, (b) valid, with s/key,
 or (c) invalid -- with a _credible_ s/key challenge.

   Of course this is aesthetically unpleasant and may be confusing
 to the user. So have it configurable somewhere.

 	mjl
>Unformatted:

Home	PR Database Search