NetBSD Problem Report #2075

From gnats  Tue Feb 13 15:49:11 1996
Received: from rupert.oscs.montana.edu by pain.lcs.mit.edu (8.6.12/8.6.12) with ESMTP id OAA24615 for <gnats-bugs@gnats.netbsd.org>; Tue, 13 Feb 1996 14:44:26 -0500
Message-Id: <199602131943.MAA06491@rupert.oscs.montana.edu>
Date: Tue, 13 Feb 1996 12:43:59 -0700
From: Chris Jones <cjones@rupert.oscs.montana.edu>
Reply-To: cjones@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: change root login failures to LOG_WARNING?
X-Send-Pr-Version: 3.95

>Number:         2075
>Category:       security
>Synopsis:       change root login failures to LOG_WARNING?
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    cjones
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 13 15:50:01 +0000 1996
>Closed-Date:    Mon Aug 15 17:16:29 +0000 2005
>Last-Modified:  Mon Aug 15 17:16:29 +0000 2005
>Originator:     Chris Jones
>Release:        1.1
>Organization:
***********************cjones@rupert.oscs.montana.edu*********************
* Chris  | "You can't say that Microsoft hasn't ever put the buggy       *
*  Jones |  before the horse."                             -Mark Wistey  *
**************************************************************************
>Environment:
System: NetBSD rupert.oscs.montana.edu 1.1 NetBSD 1.1 (SLIM) #0: Wed Nov 22 13:02:54 MST 1995 cjones@rupert.oscs.montana.edu:/home/src/sys/arch/mac68k/compile/SLIM mac68k


>Description:
Maybe root login failures should be changed from LOG_NOTICE to
LOG_WARNING, to put them in a separate class from general login
failures.  I'd think that most sysadmins would be much more concerned
about root login failures than other login failures.

>How-To-Repeat:
I can either get a log of all login (and su) failures, or I can get a
log of none.  I'd like to be able to get a log of only the ones that
could represent a serious security breach, though.

>Fix:
This will require changing login, su, and probably some kerberos
things.  I could make up a patch for login and su, but it would take a
while, since I'm not familiar with them and don't have tons of free
time.  If I get around to it, I'll submit another pr.
>Release-Note:
>Audit-Trail:

From: Chris Jones <cjones@rupert.oscs.montana.edu>
To: gnats-bugs@NetBSD.ORG, netbsd-bugs@NetBSD.ORG
Cc:  Subject: Re: bin/2075: change root login failures to LOG_WARNING? 
Date: Wed, 14 Feb 1996 18:59:38 -0700

 Here's a patch for /usr/src/usr.bin/login/login.c.  Please don't close
 the PR yet, as su and kerberos still need to be patched.

 *** login.c	Wed Feb 14 18:42:53 1996
 --- login.c.old	Wed Feb 14 17:31:50 1996
 ***************
 *** 302,312 ****
   			    "%s login refused on this terminal.\n",
   			    pwd->pw_name);
   			if (hostname)
 ! 				syslog(LOG_WARNING,
   				    "LOGIN %s REFUSED FROM %s ON TTY %s",
   				    pwd->pw_name, hostname, tty);
   			else
 ! 				syslog(LOG_WARNING,
   				    "LOGIN %s REFUSED ON TTY %s",
   				     pwd->pw_name, tty);
   			continue;
 --- 302,312 ----
   			    "%s login refused on this terminal.\n",
   			    pwd->pw_name);
   			if (hostname)
 ! 				syslog(LOG_NOTICE,
   				    "LOGIN %s REFUSED FROM %s ON TTY %s",
   				    pwd->pw_name, hostname, tty);
   			else
 ! 				syslog(LOG_NOTICE,
   				    "LOGIN %s REFUSED ON TTY %s",
   				     pwd->pw_name, tty);
   			continue;
 ***************
 *** 640,665 ****
   badlogin(name)
   	char *name;
   {
 - 	int loglevel;
 - 
 - 	/* root login failures are a bigger deal than others: */
 - 	if (pwd->pw_uid == 0)
 - 		loglevel = LOG_WARNING;
 - 	else
 - 		loglevel = LOG_NOTICE;
 - 
   	if (failures == 0)
   		return;
   	if (hostname) {
 ! 		syslog(loglevel, "%d LOGIN FAILURE%s FROM %s",
   		    failures, failures > 1 ? "S" : "", hostname);
 ! 		syslog(LOG_AUTHPRIV|loglevel,
   		    "%d LOGIN FAILURE%s FROM %s, %s",
   		    failures, failures > 1 ? "S" : "", hostname, name);
   	} else {
 ! 		syslog(loglevel, "%d LOGIN FAILURE%s ON %s",
   		    failures, failures > 1 ? "S" : "", tty);
 ! 		syslog(LOG_AUTHPRIV|loglevel,
   		    "%d LOGIN FAILURE%s ON %s, %s",
   		    failures, failures > 1 ? "S" : "", tty, name);
   	}
 --- 640,657 ----
   badlogin(name)
   	char *name;
   {
   	if (failures == 0)
   		return;
   	if (hostname) {
 ! 		syslog(LOG_NOTICE, "%d LOGIN FAILURE%s FROM %s",
   		    failures, failures > 1 ? "S" : "", hostname);
 ! 		syslog(LOG_AUTHPRIV|LOG_NOTICE,
   		    "%d LOGIN FAILURE%s FROM %s, %s",
   		    failures, failures > 1 ? "S" : "", hostname, name);
   	} else {
 ! 		syslog(LOG_NOTICE, "%d LOGIN FAILURE%s ON %s",
   		    failures, failures > 1 ? "S" : "", tty);
 ! 		syslog(LOG_AUTHPRIV|LOG_NOTICE,
   		    "%d LOGIN FAILURE%s ON %s, %s",
   		    failures, failures > 1 ? "S" : "", tty, name);
   	}



From: Chris Jones <cjones@rupert.oscs.montana.edu>
To: gnats-bugs@NetBSD.ORG, netbsd-bugs@NetBSD.ORG
Cc:  Subject: Re: bin/2075: change root login failures to LOG_WARNING? 
Date: Wed, 14 Feb 1996 19:59:53 -0700

 Here's a patch for su.  Please note that this doesn't directly fix the
 problem in my pr; incorrect passwords are all reported at a priority
 of LOG_WARNING.  I did, however, change the kerberos section of su so
 that it will report incorrect passwords with the same priority,
 instead of LOG_NOTICE, which was the previous.  Maybe this should be
 in a different pr...

 It's also possible that su should report bad passwords to both
 LOG_AUTH and LOG_AUTHPRIV, like login does.  That's a judgment call
 that I'm not going to make.

 As for kerberos, I'm not familiar with it, and consequently I don't
 know which, if any, files should be changed.  Please either close the
 pr if this all doesn't apply to kerberos, or leave it open if it does.

 *** su.c.old	Wed Feb 14 17:31:56 1996
 --- su.c	Wed Feb 14 19:29:55 1996
 ***************
 *** 364,370 ****
   		}
   		(void)fprintf(stderr, "su: unable to su: %s\n",
   		    krb_err_txt[kerno]);
 ! 		syslog(LOG_NOTICE|LOG_AUTH,
   		    "BAD Kerberos SU: %s to %s%s: %s",
   		    username, user, ontty(), krb_err_txt[kerno]);
   		return (1);
 --- 364,370 ----
   		}
   		(void)fprintf(stderr, "su: unable to su: %s\n",
   		    krb_err_txt[kerno]);
 ! 		syslog(LOG_WARNING|LOG_AUTH,
   		    "BAD Kerberos SU: %s to %s%s: %s",
   		    username, user, ontty(), krb_err_txt[kerno]);
   		return (1);
 ***************
 *** 398,404 ****
   	} else if (kerno != KSUCCESS) {
   		(void)fprintf(stderr, "Unable to use TGT: %s\n",
   		    krb_err_txt[kerno]);
 ! 		syslog(LOG_NOTICE|LOG_AUTH, "failed su: %s to %s%s: %s",
   		    username, user, ontty(), krb_err_txt[kerno]);
   		dest_tkt();
   		return (1);
 --- 398,404 ----
   	} else if (kerno != KSUCCESS) {
   		(void)fprintf(stderr, "Unable to use TGT: %s\n",
   		    krb_err_txt[kerno]);
 ! 		syslog(LOG_WARNING|LOG_AUTH, "failed su: %s to %s%s: %s",
   		    username, user, ontty(), krb_err_txt[kerno]);
   		dest_tkt();
   		return (1);
 ***************
 *** 416,422 ****
   			(void)fprintf(stderr,
   			    "su: unable to verify rcmd ticket: %s\n",
   			    krb_err_txt[kerno]);
 ! 			syslog(LOG_NOTICE|LOG_AUTH,
   			    "failed su: %s to %s%s: %s", username,
   			     user, ontty(), krb_err_txt[kerno]);
   			dest_tkt();
 --- 416,422 ----
   			(void)fprintf(stderr,
   			    "su: unable to verify rcmd ticket: %s\n",
   			    krb_err_txt[kerno]);
 ! 			syslog(LOG_WARNING|LOG_AUTH,
   			    "failed su: %s to %s%s: %s", username,
   			     user, ontty(), krb_err_txt[kerno]);
   			dest_tkt();


State-Changed-From-To: open->analyzed 
State-Changed-By: fair 
State-Changed-When: Tue Jul 7 23:25:56 PDT 1998 
State-Changed-Why:  

This looks like a reasonable change to make; are there any other subsystems 
which need to be patched to deal? ftpd? rshd? I've also adjusted the 
category of this PR from "bin" to "security" since that's what the issue is. 

Responsible-Changed-From-To: bin-bug-people->security-officer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Thu Jan 14 01:13:24 PST 1999 
Responsible-Changed-Why:  

New lucky sot. 

Responsible-Changed-From-To: security-officer->cjones 
Responsible-Changed-By: fair 
Responsible-Changed-When: Sun Jan 30 12:50:53 PST 2000 
Responsible-Changed-Why:  

The submitter is now a developer. One proviso, though: be mindful that every 
poor system administrator has to read a lot of log data, and too many notices 
is often a worse state of affairs than too few, in that things are more easily 
lost in the noise. 

From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: tech-security@netbsd.org
Subject: re: security/2075
Date: Sun, 14 Aug 2005 20:52:25 +0300

 Hi,

 I'm about to close this PR for the following reasons:

 1. Maybe in 1996 a failed root login was an anomaly; today it's just
    noise.

 2. The proposed fix, or any fix for the outlines ``problem'' in the PR,
    would require changes in too many parts of the tree which may not be
    desired by most admins.

 3. Public keys, disallowing remote root logins in ssh, ftp, are common
    practice.

 4. An attacker trying to brute-force an account password (with or
    without a master.passwd), let alone the root password, is very
    uncommon; I believe the majority, if not all, of inexperienced
    attackers today will attempt to run their arsenal of exploits on a
    target system.

    Experienced attackers will attempt their *private* arsenal of
    exploits on a target system. :)

 5. Many tools allow specifying log facility and/or priority; if any
    modification is to be done at all, and I certainly think that there
    should be *no* modification (!), it should be to allow an admin
    specify log facility/priority. Changing the default is bad.

 6. There are a variety of log monitoring tools and brute-force attack
    mitigation methods; if an admin cares enough, there are better
    ways to handle with it.

 7. Filtering what a specific admin cares about from the logfiles should
    be done by log monitoring tools. If an admin does it manually,
    probably using ``egrep'', it certainly makes no difference in what
    file these logs are in.

 And there are plenty more.. :)

 -e.

 -- 
 Elad Efrat
 PGP Key ID: 0x666EB914

State-Changed-From-To: analyzed->closed
State-Changed-By: elad@netbsd.org
State-Changed-When: Mon, 15 Aug 2005 17:16:29 +0000
State-Changed-Why:
http://mail-index.netbsd.org/tech-security/2005/08/14/0000.html


>Unformatted:

Home	PR Database Search