COMMAND
NIS+
SYSTEMS AFFECTED
Solaris 2.x up to Solaris 2.5.1 using NIS+
PROBLEM
Following info is based on Secure Networks Inc. advisory (SNI-27)
in conjunction with CORE SDI S.A. The Network Information Server
Plus (NIS+) is a network directory service that provides
management and resource location support (including authentication
and name resolution) to heterogenous distributed systems. NIS+,
which replaces the original NIS (also known as "YP"), is made
available to a network via the ONC RPC mechanism, which allows
NIS+ clients to interact with the server using remote procedure
calls over a network. The principle server program that supports
this is "rpc.nisd", the RPC NIS+ daemon. Because the services
provided by NIS+ are security-critical, NIS+ is designed to
operate securely. An aspect of this design is the concept of
"security levels", which determine the amount of scrutiny given to
incoming RPC NIS requests.
There are three security levels, numbered 0 through 2. In level 0,
the NIS+ server (rpc.nisd) performs no authentication to determine
the legitimacy of incoming requests. This option is provided for
debugging purposes. In level 1, RPC AUTH_UNIX (client-presented
UIDs and GIDs) are used to authenticate requests. In level 2, the
most secure level, AUTH_DES is used to cryptographically
authenticate incoming requests. Unfortunately, even when the
system is operating in security level 2, which should mandate
cryptographic authentication for all requests, the rpc.nisd daemon
provides several RPC calls that are not authenticated. These
calls allow a remote client to obtain sensitive system status
information from the NIS+ server.
The information available to a remote attacker includes NIS+
configuration information (including the security level of the
server and a list of directory objects served by it), as well as
the ability to determine valid process IDs on the NIS+ server.
Additionally, one of the RPC calls available to remote clients can
allow an attacker to disable logging on the NIS+ server, as well
as to manipulate the NIS+ caches. This may allow attackers to
degrade or deny service on NIS+ servers. The ability to use NIS+
to remotely ascertain valid process IDs is serious because it
allows an attacker the ability to predict certain random numbers
generated by Unix applications. Frequently, Unix applications
generate random numbers using the process ID and the current time,
either directly or as a seed to a random number generator.
Three remote procedure calls made available by the NIS+ daemon
"rpc.nisd" have been identified. These are:
A. NIS_CALLBACK
===============
Using the NIS_CALLBACK RPC, arbitrary clients can determine the
validity of a given PID (or, using multiple queries, to map out
the identities of all valid process IDs).
B. NIS_STATUS
=============
Using the NIS_STATUS RPC, arbitrary clients can obtain information
about the NIS+ server configuration, including:
1. The server security level.
2. Whether the server is operating in NIS/YP compatibility
mode.
3. Whether the server is a root NIS+ server.
4. Whether it is using it's own DNS resolver or forwarding DNS
requests.
5. The list of all directory objects provided by this server.
C. NIS_SERVSTATE
================
Using the TAG_DEBUG option to this RPC, any remote user can turn
off all rpc.nisd logging. Using the TAG_*CACHE (D, for directory,
T, for table, and G, for group) option, the directory, table, and
group caches can be flushed.
SOLUTION
These problems can be worked around using packet filters to block
UDP traffic to the NIS+ server. Blocking UDP to the NIS+ server
from valid NIS+ clients will cause the NIS+ system to fail. Sun
has been notified of this problem and is working on a fix.