Note: This is an archival copy of Security Sun Alert 200825 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000624.1.
Solaris 9 Operating System
Solaris 2.6 Operating System
Solaris 7 Operating System
Solaris 8 Operating System
Date of Workaround Release
Date of Resolved Release
A local or remote unprivileged user may be able to kill rpcbind(1M) due to a security vulnerability in the network services library, libnsl(3LIB). Exploiting this vulnerability may lead to denial of service. Although Sun is not aware of any other applications or services that may be vulnerable to this issue, Sun is continuing to investigate and will update this Sun Alert as needed.
This issue is also described in CERT Vulnerability VU#516825 (see http://www.kb.cert.org/vuls/id/516825) which is referenced in CERT Advisory CA-2003-10 (see http://www.cert.org/advisories/CA-2003-10.html).
Thanks to Riley Hassell of eEye Digital Security and Garry Zacheiss of MIT for reporting this issue.
This issue can occur in the following releases:
Notes: Solaris 2.5.1 will not be evaluated for potential impact for the described issue contained in this Sun Alert document.
If SEAM(5) is installed, the following Kerberos application which runs with root privileges is affected:
Executing the following command will not show the rpcbind(1M) daemon as running:
$ /bin/ps -ef | grep rpcbind
Remote users may not be able to access network services such as YP, NIS+, NFS on the affected system.
Error messages similar to the following may be found in the message log, /var/adm/messages:
Mar 9 12:41:35 dummy rpcbind: xdrmem_getbytes: Incoming data too large, Mar 9 13:43:54 dummy rpcbind: rpcbind terminating on signal. Mar 9 13:44:59 dummy rpcbind: xdrmem_getbytes: Incoming data too large, Mar 9 13:45:32 dummy rpcbind: xdrmem_getbytes: Incoming data too large,
On the affected system a core file may be generated in the root directory, '/'. A root user may run file(1) on the core file to determine the original program, for example:
# file /core /core: ELF 32-bit MSB core file SPARC Version 1, from 'rpcbind'
A typical stack trace from a failed exploit attempt against "rpcbind" may look like:
=> _memcpy(0xeffdda1c, 0xff01dab6, 0x2, 0x0, 0x0, 0xeffdda1c), at 0xef670580  xdrmem_getbytes(0x2b37c, 0xeffdda1c, 0x2, 0x0, 0x0, 0x0), at 0xef6a7bb4  xdr_opaque(0x2b37c, 0xeffedc50, 0xfefefefe, 0x5, 0xef6254fc, 0x2), at 0xef697b50  xdr_bytes(0x2b37c, 0xefffdc68, 0xefffdc64, 0xffffffff, 0xfefefefe, 0xeffedc50), at 0xef69e844 ...  my_svc_run(0x6, 0x2a540, 0x1, 0xc3, 0x320978, 0xd), at 0x15268  main(0x29334, 0xefffff1c, 0x2d0b8, 0x0, 0x0, 0x0), at 0x16734
There is no workaround for this issue, but one may wish to block access to the vulnerable services as described in the following paragraphs.
The following text is based on the wording in CERT Advisory CA-2003-10:
Until patches are available and can be applied, you may wish to block access to the affected services listed above from untrusted networks such as the Internet or disable the daemons where possible. Use a firewall or other packet-filtering technology to block the appropriate network ports. Consult your vendor or your firewall documentation for detailed instructions on how to configure the ports. The rpcinfo(1M) command will report the network port(s) in use by each of the above RPC based daemons. The RPC portmapper service, rpcbind(1M), typically runs on ports 111/tcp and 111/udp. Although the following will not safeguard rpcbind(1M) against the vulnerability, a proactive approach can be taken to avoid restarting the registered RPC services after rpcbind was killed during an attack. After all the RPC services that run on the local machine have started send a SIGTERM to the rpcbind process: # pkill -TERM rpcbind This will result in rpcbind(1M) writing a list of currently registered services to the /tmp/rpcbind.file and /tmp/portmap.file before the rpcbind process itself exits. Then perform a subsequent warm restart of the rpcbind process: # /usr/sbin/rpcbind -w This will restart rpcbind and register all the services that were previously written to the temporary files mentioned earlier. Some third-party applications may have been created and installed which are statically linked with the static version of the name services library, libnsl.a. If this is the case, then it will be necessary to obtain an application upgrade or patch from the application vendor once patches for this issue are available.
This issue is addressed in the following releases:
This solution has no attachment