From dada@freepass.tu-graz.ac.at  Mon Apr 14 03:39:38 1997
Received: from freepass.tu-graz.ac.at (freepass.tu-graz.ac.at [129.27.193.133])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA02091
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Apr 1997 03:32:39 -0700 (PDT)
Received: (from dada@localhost) by freepass.tu-graz.ac.at (8.6.11/8.6.9) id MAA13940; Mon, 14 Apr 1997 12:32:29 +0200
Message-Id: <199704141032.MAA13940@freepass.tu-graz.ac.at>
Date: Mon, 14 Apr 1997 12:32:29 +0200
From: Martin Kammerhofer <dada@freepass.tu-graz.ac.at>
Reply-To: dada@sbox.tu-graz.ac.at
To: FreeBSD-gnats-submit@freebsd.org
Subject: login(1) does not check /etc/skey.access when doing local logins
X-Send-Pr-Version: 3.2

>Number:         3289
>Category:       bin
>Synopsis:       login(1) does not check /etc/skey.access when doing local logins
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 14 03:40:43 PDT 1997
>Closed-Date:    Mon May 18 02:32:32 PDT 1998
>Last-Modified:  Mon May 18 02:38:28 PDT 1998
>Originator:     Martin Kammerhofer
>Release:        FreeBSD 2.2.1-RELEASE i386
>Organization:
Graz University of Technology
>Environment:
	2.2.1 system with SKEY
	File /etc/skey.access containing one line (follows here):
permit internet 127.0.0.1 255.255.255.255

>Description:
	local logins are possible from ttyv? (i.e. console) only,
	BUT according to skey.access ALL LOCAL logins should be allowed
	with UNIX passwords.

>How-To-Repeat:
	Install the above quoted line in file /etc/skey.access
	and try from any non-console terminal /usr/bin/login
	(The login binary must be compiled with SKEY).
	E.g. try "xterm -e login".

>Fix:
	Apply the following patch to login.c, note that this makes login(1)
	assume any invocation without option -h <host> is from localhost
	when login(1) decides wether to permit UNIX-passwords.
	AFAIK this assumption is valid.

--- login.c~	Tue Apr  8 23:58:54 1997
+++ login.c	Wed Apr  9 01:05:30 1997
@@ -282,7 +282,7 @@
 
 #ifdef	SKEY
 		permit_passwd = skeyaccess(username, tty,
-					   hostname ? full_hostname : NULL,
+					   hostname ? full_hostname : "localhost",
 					   NULL);
 		p = skey_getpass("Password:", pwd, permit_passwd);
 		ep = skey_crypt(p, salt, pwd, permit_passwd);
>Release-Note:
>Audit-Trail:

From: A Joseph Koshy <koshy@india.hp.com>
To: freebsd-gnats-submit@freebsd.org
Cc: phk@freebsd.org, steve@freebsd.org
Subject: Re: bin/3289: login(1) does not check /etc/skey.access when doing ...
Date: Tue, 12 May 1998 10:26:15 +0530

 Interesting PR, but unfortunately the fix given opens a security hole.
 
 Here is the scenario:
 
 	1. User logs into machine over an insecure network using s/key.
 
 	2. User runs 'sh -c login' : with the given patch this will be
 	   treated as a login from 'localhost' allowing a line like
 	   'internet 127.0.0.1 255.255.255.255' in "/etc/skey.access" to
 	   allow unix passwords to be used.
 
 	   This means that the password would be transmitted over the 
 	   insecure network.
 
 The only logins that are special to S/Key are those from the machine 
 ``console''.  A login via say, xterm(1) is not ``local'' to S/Key, and
 to be fair, the man page does not claim otherwise.  S/Key is working
 according to spec.
 
 Determining if a login on a psuedo-tty is really "local" without opening
 oneself up to security holes like the above is going to be hard.  I'm
 also not sure whether it is worth convoluting the login(1) code for this.
 
 The problem in the PR really affects only those users who do not have S/Key 
 passwords when S/Key is enabled systemwide.  Users with S/Key passwords 
 would be to login using their s/key passwords.
 
 Workarounds:
 
 I.	If you are going to enable S/Key, ensure that every user has
 	S/Key passwords.
 
 	(I prefer this).
 
 II.	Have a line like 'internet 127.0.0.1 255.255.255.255' in 
 	"/etc/skey.access" and use sudo(1) to run 'login -h localhost'
 
 Here is a patch to the skey.access manual page to make this caveat
 clear (the patch will apply to both -current and -stable):
 
 
 # diff -u skey.access.5-- skey.access.5
 --- skey.access.5--     Wed Oct 19 00:03:23 1994
 +++ skey.access.5       Tue Sep 23 06:43:06 1997
 @@ -76,6 +76,15 @@
  .I internet
  keyword may be omitted from net/mask patterns.
  .SH WARNINGS
 +When the S/Key control table (\fI/etc/skey.access\fR)
 +exists, users without S/Key passwords will be able to login only
 +where the rules allow the use of UNIX passwords.  In particular, this
 +means that an invocation of \fIlogin(1)\fR in a pseudo-tty (e.g. from
 +within \fIxterm(1)\fR or \fIscreen(1)\fR) will be treated as a login
 +that is neither from the console nor from the network, mandating the use
 +of an S/Key password.  Since such users do not have an S/Key password
 +the invocation of \fIlogin(1)\fR will necessarily fail.
 +.PP
  Several rule types depend on host name or address information obtained
  through the network.  What follows is a list of conceivable attacks to
  force the system to permit UNIX passwords.
 
 
 The PR can be closed as a user misunderstanding I guess ...
 
 Regards,
 Koshy
State-Changed-From-To: open->closed 
State-Changed-By: jkoshy 
State-Changed-When: Mon May 18 02:32:32 PDT 1998 
State-Changed-Why:  
Warning about interaction of S/Key and login(1) for users without S/Key 
passwords added to man page for skey.access(5). 
(rev 1.3 of skey.access.5) 
>Unformatted:
