NIS+ vulnerability
Clifford Wesley Fulford (cwf@soc.unl.ac.uk)
Thu, 30 May 1996 16:14:04 +0100
Further to the security advisory bulletins mentioned below. I believe
that while the advisory bulletins are useful in so far as they go a key
element is still missing. I attach below the text of a proposed
further bulletin regarding entry permissions on NIS+ password tables.
-----------------------------------------------------------------------
CERT Advisory CA-96.10 CIAC Advisory G-23
Topic: NIS+ configuration
Vulnerability
-----------
The vulnerability to mis-configuration of the NIS+ passwd table extends beyond
that described in the above bulletins.
All sites which use the command line or scripts to create user accounts are
potentially vulnerable.
Description.
-----------
The problem occurs when additions to the table are made from the command line
or in a script.
In addition to the table and column permissions as described in the above
referenced bulletins consideration must be given
to the entry permissions. By default the entry's owner has modify permission
on their entry. This is known to be a problem at least up to Solaris 2.4.
The permissions on an entry may be seen with the command
niscat -o [name=username],passwd.org_dir.
This will produce output similar to
Object Name : passwd
Owner : hostname.domainname.
Group : admin.domainname.
Domain : org_dir.domainname.
Access Rights : ----rmcdr---r---
Time to Live : 12:0:0
Object Type : ENTRY
Entry data of type passwd_tbl
[1] - [4 bytes] 'username'
[2] - [14 bytes] Encrypted data
[3] - [4 bytes] '586'
[4] - [4 bytes] '220'
[5] - [31 bytes] 'An Illustrative User Name'
[6] - [16 bytes] '/home/ugrad/username'
[7] - [9 bytes] '/bin/ksh'
[8] - [24 bytes] Encrypted data
It is the owners permissions here that are critical. The owner has modify
rights on their own entry.
By default the entry will be owned by the creator (hostname.domain. if
created by root or adminuser.domain. if created by a member of the
NIS+ domain's admin group) but its is usual to change
the owner to user to permit password changes (this is done automatically
if using admintool).
If the owner now logs on and issues the command
nistbladm -m uid=0 [name=username],passwd.org_dir
he or she will gain root privileges. (It may take a little while for the new
UID to be disseminated if there are replica servers which are servicing the NIS+
requests faster than the master). No special privileges such admin group
membership are required to do this.
Workarounds
-----------
To change the permissions on the entry the command
nischmod na=,o=r [name=username],passwd.org_dir
Now if we look at the permissions on the entry we should see.
Object Name : passwd
Owner : username.domainname.
Group : admin.domainname.
Domain : org_dir.domainname.
Access Rights : ----r-----------
Time to Live : 12:0:0
Object Type : ENTRY
Entry data of type passwd_tbl
[1] - [4 bytes] 'username'
[2] - [14 bytes] Encrypted data
[3] - [4 bytes] '586'
[4] - [4 bytes] '220'
[5] - [31 bytes] 'An Illustrative User Name'
[6] - [16 bytes] '/home/ugrad/username'
[7] - [9 bytes] '/bin/ksh'
[8] - [24 bytes] Encrypted data
Again these are the permissions and ownership that would be set using
admintool.
I can provide scripts to change all user entries to the correct ownership
and permissions (this should be done immediately by any sites who identify
this problem) and account creation scripts that will create new users with
secure permission.
Clifford W. Fulford.
CBF-International.
Currently at
University of North London
ISS-UNIX development
E-mail: Clifford@soc.unl.ac.uk
Clifford@cix.compulink.co.uk
C.Fulford@unl.ac.uk
Telephone: 0171-607-2789 x 7314. Home 0181-986-5239