From root@zeus.engg.ucalgary.ca  Tue Aug 20 19:52:35 1996
Received: from zeus.engg.ucalgary.ca (pc26.engg.ucalgary.ca [136.159.114.26])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01277
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Aug 1996 19:52:34 -0700 (PDT)
Received: (from root@localhost) by zeus.engg.ucalgary.ca (8.7.5/8.7.3) id UAA00889; Tue, 20 Aug 1996 20:52:31 -0600 (MDT)
Message-Id: <199608210252.UAA00889@zeus.engg.ucalgary.ca>
Date: Tue, 20 Aug 1996 20:52:31 -0600 (MDT)
From: Gord Matzigkeit <gord@gnu.ai.mit.edu>
Reply-To: gord@gnu.ai.mit.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: chpass creates an NIS security hole
X-Send-Pr-Version: 3.2

>Number:         1519
>Category:       bin
>Synopsis:       chpass creates an NIS security hole
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    wpaul
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 20 20:00:02 PDT 1996
>Closed-Date:    Mon Oct 21 20:54:42 PDT 1996
>Last-Modified:  Mon Oct 21 21:00:23 PDT 1996
>Originator:     
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
Profit Press
>Environment:

FreeBSD 2.1.5-RELEASE #1: Tue Aug 20 02:52:03 MDT 1996
root@zeus.engg.ucalgary.ca:/usr/src/sys/compile/ZEUS

>Description:

If you use chpass -a, as root, to add the NIS magic cookie to your
/etc/master.passwd file, then it will create a line that looks like:

 +::0:0::0:0:::

pwd_mkdb expands this to:

 +:*:0:0:::

I cite the passwd(5) manual page:

  This is important to remember because most people are accustomed to using
  an NIS wildcard entry that looks like this:

	+:*:0:0:::

  This often leads to new FreeBSD administrators choosing NIS entries for
  their master.passwd files that look like this:

	+:*:0:0::::::

  Or worse, this

	+::0:0::::::

  DO _NOT_ PUT ENTRIES LIKE THIS IN YOUR master.passwd FILE!! The first
  tells FreeBSD to remap all passwords to `*' (which will prevent anybody
  from logging in) and to remap all UIDs and GIDs to 0 (which will make ev-
  erybody appear to be the superuser). The second case just maps all UIDs
  and GIDs to 0, which means that all users will appear to be root!

It seems that chpass(1) should be aware of the above conditions, and
avoid them if possible.

>How-To-Repeat:

As root, innocently run:

zeus:/# chpass -a '+:::::::::'
chpass: rebuilding the database...
chpass: done
zeus:/# tail -1 /etc/master.passwd
+::0:0::0:0:::
zeus:/# tail -1 /etc/passwd
+:*:0:0:::
zeus:/#

>Fix:
	
Unknown
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->wpaul 
Responsible-Changed-By: wosch 
Responsible-Changed-When: Thu Sep 26 16:56:31 PDT 1996 
Responsible-Changed-Why:  
Mr. NIS 

State-Changed-From-To: open->closed 
State-Changed-By: wpaul 
State-Changed-When: Mon Oct 21 20:54:42 PDT 1996 
State-Changed-Why:  

Fixed in both -current and -stable versions of pwd_mkdb and 
chpass. The problem is that both programs fail to distinguish 
between a properly specified 0 value in a numerical passwd or 
master.passwd field and an empty value. Both programs properly 
set the bits in pw_fields correctly when a real value is present, 
but neither one uses this information when generating the updated 
passwd or master.passwd file. 

Since rpc.yppasswdd in FreeBSD-current allows additions and 
uses almost the same code as chpass when updating the NIS 
master.passwd template file, it has been patched too. 
>Unformatted:
Gord Matzigkeit <gord@gnu.ai.mit.edu>
