Date: Fri Sep 20 11:44:02 PDT 1991 Subject: Security Digest V3 #13 Security Digest Volume 3 Issue 13 subject(s): delay in "YP is not secure" postings Re: YP is not secure Re: YP is not secure Re: YP is not secure The unix security mailing list is by invitation only and often contains sensitive material which IS NOT INTENDED FOR PUBLIC DISSEMINATION. PLEASE DO NOT PUT ANY SECURITY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS. PLEASE SEND NEW SECURITY HOLES TO: holes@uninet.cpd.com PLEASE POST NORMAL MESSAGES TO: security@uninet.cpd.com PLEASE SEND EMERGENCY ALERTS TO: security-emergency@uninet.cpd.com PLEASE SEND REQUESTS TO: security-request@uninet.cpd.com Postings that describe security holes/fixes have a * in their subject. ------------------------------------------------------------------------ Date: Sat, 14 Sep 91 14:45:29 PDT From: neil (Neil Gorsuch) Subject: delay in "YP is not secure" postings [ Oops, I forgot to mention that the yellow pages (all right, NIS) postings in the last digest were old stuff. I found them in a file that the security list scripts had misplaced about a year ago, and after checking the archives to see that they hadn't already appeared on the list before, went ahead and posted them. Sorry about the confusion, seemed like they couldn't hurt and maybe would be helpful. Sheesh, this is what I get for trying to liven things up 8-) - neil ] ------------------------------------------------------------------------ Date: Fri, 13 Sep 1991 23:57:15 -0400 From: Mark Moraes Subject: Re: YP is not secure I wish you would not strip off the Date: from the messages in the digest. I can't even remember how long ago I sent in the comments about YP not being secure. [ all sorts of stuff was missing from the files that I found, including portions of the text (I think), and most of the headers, so I just posted what I could piece together. I have various software that munges headers and other stuff in incoming postings automatically, and those misplaced files I found must have gone through a test version of that software. The only header line in them was the from: line. - neil ] ------------------------------------------------------------------------ Date: Sat, 14 Sep 1991 13:06:14 -0400 From: Mark Moraes Subject: Re: YP is not secure Sigh. I do know about -ypset and -ypsetme options (not that they'll convince us to run YP:-). I sent that message to the security list well over a year ago (I think sometime in April 1990, but I can't be sure since Neil helpfully deleted the Date: header from that message) in response to someone complaining that ypserv would hand out password files to anyone who asked. 4.1 was either very new or not yet out at that time, I don't remember which. Neil, PLEASE would you drop a note to the mailing list indicating the delay in these articles -- perhaps you can enclose Rob's note as well, since it does summarize the current state of SunOS YP security. [ It's included below - neil ] -------------------------------------------------------------------------- Date: Sat, 14 Sep 1991 10:03:13 -0400 From: Rob McMahon Subject: Re: YP is not secure > - ypbind will happily accept ypset requests from the network to change the > ypserv for a domain. Fixed, at least at 4.1. ypbind requires a `-ypset' to allow anyone to use ypset and `-ypsetme' to accept requests from the local machine. `ypbind -s' means that the ypserv it does bind to must be running on a privileged port (of course this doesn't stop your PC hacker. > - anyone on your machine can start up their own ypbind -- the old > ypbind will gracefully(!) yield to it. Run `ypbind -s', then they have to be root to do it (in which case you're in trouble anyway). Once again, having machines on your local network where you don't trust root will get you in trouble. > I suspect it is possible to have a machine on your ethernet that listens for > YP broadcast requests and replies quickly, beating out the real ypserv. Fixed by `ypbind -s' if you trust root. I think 4.1{,.1} fixes most of your worries. The one worry I'm left with is whether people can read our `passwd.adjunct.byname' map. I suspect this is rather easy. ------------------------------------------------------------------------ End of Security Digest Volume 3 Issue 13 **********************