The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V3 #13 1991-09-20 (1 file, 2039 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Fri Sep 20 11:44:02 PDT 1991
Subject: Security Digest V3 #13

Security Digest Volume 3 Issue 13


            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

PLEASE SEND NEW SECURITY HOLES TO:              [email protected]
PLEASE POST NORMAL MESSAGES TO:              [email protected]
PLEASE SEND REQUESTS TO:             [email protected]

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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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