Subject: bin/953: login.c changes to sanify s/key use
To: None <gnats-admin@NetBSD.ORG>
From: None <tls@sdinter.net>
List: netbsd-bugs
Date: 04/11/1995 02:20:06
>Number:         953
>Category:       bin
>Synopsis:       S/KEY should always be used on lines not marked secure in ttys.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 11 02:20:03 1995
>Originator:     Thor Lancelot Simon
>Organization:
"	Wasabi Informatics, Inc."
>Release:        1.0
>Environment:
	
System: NetBSD sioux.sdinter.net 1.0 NetBSD 1.0 (FALLS) #12: Fri Mar 17 08:39:13 CST 1995 root@sioux.sdinter.net:/usr/src/sys/arch/i386/compile/FALLS i386


>Description:
	Allowing users with skeykeys entries to log in using reusable passwords
  is only reasonable on lines marked "secure" in /etc/ttys.  If the line isn't
  secure enough for root to log in, and you're concerned enough about security
  to be using one-time passwords, then you shouldn't allow nefarious individuals
  to use sniffed passwords to log in even if the user has an s/key!  The
  present usage introduces a severe hole into the conceptual security of the
  s/key mechanism.  Since the "secure" tty state is already used by login,
  using it for this doesn't introduce much complexity.  If you think a
  distinction should be made between "secure for root logins" and "secure from
  sniffing" ttys, another ttys flag could be used or -- and I very, very
  strongly suggest this, and will implement it if you like -- s/key should be
  required on logins by s/keyed users on pseudoterminals.  This still doesn't
  solve what I see as the need in highly security-conscious environments to
  require s/key on arbitrary sets of terminals.  

  I find that the policy imposed by the following patch is more secure than the
  current default policy and actually works quite well in real-world
  environments.

>How-To-Repeat:
	Learn someone's password by nefarious means, and then use it to log
  in, even though he has an s/key.  That's not cool.
>Fix:

*** login.c~	Tue May 24 01:51:03 1994
--- login.c	Sat Mar 18 23:12:06 1995
***************
*** 250,255 ****
--- 250,260 ----
  
  		(void)setpriority(PRIO_PROCESS, 0, -4);
  
+ 		if (!skey_haskey(username) && !rootterm(tty)) {
+ 			rval = skey_authenticate(username);
+ 			goto authdone;
+ 		}
+ 
  		p = getpass("Password:");
  
  		if (pwd) {
***************
*** 261,266 ****
--- 266,272 ----
  				rval = pwcheck(username, p, salt, pwd->pw_passwd);
  #else
  			rval = pwcheck(username, p, salt, pwd->pw_passwd);
+ 
  #endif
  		}
  		bzero(p, strlen(p));
***************
*** 289,294 ****
--- 295,302 ----
  				     pwd->pw_name, tty);
  			continue;
  		}
+ 
+ authdone:
  
  		if (pwd && !rval)
  			break;

>Audit-Trail:
>Unformatted: