Date: Mon, 11 May 1998 22:00:01 -0700 (PDT) From: A Joseph Koshy <koshy@india.hp.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/3289: login(1) does not check /etc/skey.access when doing ... Message-ID: <199805120500.WAA27822@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/3289; it has been noted by GNATS. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805120500.WAA27822>