Note: This is an archival copy of Security Sun Alert 201581 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1001186.1.
Solaris 9 Operating System
Solaris 7 Operating System
Solaris 8 Operating System
Date of Resolved Release
Remote unprivileged users on NIS+ client systems may be able to disable the NIS+ service daemon, rpc.nisd(1M) which runs on NIS+ servers and implements the NIS+ service. By disabling the rcp.nisd(1M), the NIS+ service will be unavailable which is a type of denial of service. If a NIS+ server is configured as a client as well then local unprivileged users on that NIS+ server may be able to disable rpc.nisd(1M). It is also possible that a poorly written client application could similarly cause the denial of service.
This issue can occur in the following releases:
To determine if this is a NIS+ Master or Replica server, the following command can be run:
$ pgrep rpc.nisd || echo "This system is not a NIS+ server."
Also check that the rpc.nisd(1M) process is started on the system (otherwise the system does not function as a NIS+ server). The following command will show the running NIS+ service daemon rpc.nisd(1M):
# ps -ef |grep rpc.nisd
For Solaris 7 and 8 this can effectively disable the NIS+ service for that server. If the request is repeated, then another server will be disabled until all NIS+ services are disabled. For Solaris 9 the server will consume excessive CPU time executing a tight loop, but the NIS+ service will continue. Should sufficient requests be made the server will effectively become disabled.
This could affect for example, login of a user to a client system, a request to the NIS+ naming service with commands like nisls(1) or getent(1M) or telnet(1) to another system.
In addition, NIS+ servers will be showing continuous high CPU usage. This means that the output of the "ps -efl" command will show a fast increasing number for the used time of the rpc.nisd(1M) process.
To temporarily work around the described issue: restart the NIS+ server daemon, then by using snoop(1M), identify the source of the requests and either discontinue or disable it, if possible.
This issue is addressed in the following releases:
This solution has no attachment