Security Issues in Sun NIS+

Security Issues in Sun NIS+

Synopsis:
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.

Due to implementation problems, the programs supporting NIS+ can be exploited by an attacker to recover various pieces of system status information.

It is important to understand that the issues highlighted in this advisory present no immediate threat of remote compromise; with one exception (the ability to disable NIS+ logging remotely), all the vulnerabilities discussed in this advisory do nothing but leak system status and configuration information. Because NIS+ is a security-critical service, however, any security issues discovered in it are worth attention.

Description:
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.

Technical details:
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.

Vulnerable systems:
Solaris 2.x systems up to Solaris 2.5.1, making use of the Network Information Service Plus (NIS+) system, are vulnerable to these problems.

Resolution:
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.

SunSoft has been notified of this problem and is working on a fix.

Additional information:
These problems were originally identified by CORE SDI S.A., an Argentina-based computer security organization, in February of 1997.

More information about the NIS+ system is available in a technical paper from SunSoft entitled "Network Information Service Plus (NIS+)", by Chuck McManis and Saqib Jang. The paper is available at:
http://opcom.sun.ca/pub/docs/solaris/NISPlus.ps.Z

A list of frequently asked questions is available at:
http://ee.sun.ac.kr/~ramdrive/NIS+_FAQ.html

CERT Advisory CA-96.10 details a vulnerability in the NIS+ stemming from improper configuration of password table permissions. The advisory reprints AUSCERT Advisory AA-96.02. CERT advisories are available at
http://www.cert.org

A Spanish-language NIS+ reference is available at:
http://a01-unix.uc3m.es/~pduenas/nisplus.html

Further questions about this advisory can be addressed to Emiliano Kargieman <ek@core-sdi.com> and Ivan Arce at <iarce@core-sdi.com>.

About Secure Networks, Inc.:
Secure Networks, Inc. (SNI) is a security research and development company based in Calgary, Alberta, Canada. SNI is the largest independent source of full-disclosure security advisories and new vulnerability information in the world. For more information about this or other advisories, contact us at <sni@secnet.com>. A PGP key is provided if privacy is required.

For the full text of this and all of SNI's other advisories, see our web page at "http://www.secnet.com/advisories/". General information about SNI is available at "http://www.secnet.com".

Copyright Information:
The contents of this advisory are Copyright (C) 1998 Secure Networks Inc, and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given.

Locally Exploitable: 
no
Remotely Exploitable: 
no
  • Request Info

Research Blog