Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA826 ; Mon, 08 Feb 93 08:01:58 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!swrinde!emory!gatech!purdue!mentor.cc.purdue.edu!rahnds From: rahnds@mentor.cc.purdue.edu (Dale Rahn) Subject: Re: *Big* security leak for users w/o crypt. Message-ID: <C1zMJ1.J3t@mentor.cc.purdue.edu> Organization: Purdue University References: <1kmcqrINN4l@encap.hanse.de> <CGD.93Feb3180816@eden.CS.Berkeley.EDU> <CGD.93Feb4113117@eden.CS.Berkeley.EDU> Date: Fri, 5 Feb 1993 18:11:23 GMT Lines: 40 In article <CGD.93Feb4113117@eden.CS.Berkeley.EDU> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes: >In article <CGD.93Feb3180816@eden.CS.Berkeley.EDU> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes: >=>In article <1kmcqrINN4l@encap.hanse.de> maverick@encap.hanse.de (Jan-Oliver Neumann) writes: >=>[ about a problem handling starred-out passwd entries, with the dummy crypt >=> routine ] >=> >=>i'll make and post a set of diffs to fix this, so that the change will >=>hopefully get merged into the mainstream release channel... > >i don't want to know *what* i was thinking when i said this; >any change like this would be nasty, if only because of the way >the password comparisons are handled... > >if you're not using the crypt() routine (i.e. the default), >you don't define "DES" when compiling the utils that would use >crypt(), and the password check becomes something like: >"rval = strcmp(p, pwd->pw_passwd);" whereas w/crypt, it looks >like "rval = strcmp(crypt(p, salt), pwd->pw_passwd);". > >therefore to fix the problem, you'd need to modify as many files >as you would to install crypt in the first place, and the modifications >wouldn't port "easily" to other crypt-using programs... > >if you're at all concerned about security (you should be), >then just get crypt.c from somewhere, and do the right thing, >per the instructions that come w/386bsd... > > Isn't It possible to set up all "secure" accounts will invalid shells. If the shell is unavialable the login will fail it is not possible to log into thosse accounts. with the default setup most accounts are set with shell /dev/null which fails. Some are not set this way (but should be). I do not wish to list them for possible security reasons. If theses are fixed. Then it seems that that alone would give a reasonable amount of (outside) security from dialups, however these accounts would not be secure from people already logged in. Dale Rahn rahnds@mentor.cc.purdue.edu