Product
Solaris 9 Operating System
Solaris 2.6 Operating System
Solaris 7 Operating System
Solaris 8 Operating System

Bug Id
4767276

Date of Workaround Release
20-MAR-2003

Date of Resolved Release
08-MAY-2003

Impact

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.

Contributing Factors

This issue can occur in the following releases:

SPARC Platform

• Solaris 2.6 without patch 105401-44
• Solaris 7 without patch 106942-27
• Solaris 8 without patch 108993-18
• Solaris 9 without patch 113319-11

x86 Platform

• Solaris 2.6 without patch 105402-44
• Solaris 7 without patch 106943-27
• Solaris 8 without patch 108994-18
• Solaris 9 without patch 113719-04

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:

• kadmind(1M) - Kerberos administration daemon

Symptoms

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:

  =>[1] _memcpy(0xeffdda1c, 0xff01dab6, 0x2, 0x0, 0x0, 0xeffdda1c), at 0xef670580
[2] xdrmem_getbytes(0x2b37c, 0xeffdda1c, 0x2, 0x0, 0x0, 0x0), at 0xef6a7bb4
[3] xdr_opaque(0x2b37c, 0xeffedc50, 0xfefefefe, 0x5, 0xef6254fc, 0x2),
at 0xef697b50
[4] xdr_bytes(0x2b37c, 0xefffdc68, 0xefffdc64, 0xffffffff, 0xfefefefe, 0xeffedc50),
at 0xef69e844
...
[11] my_svc_run(0x6, 0x2a540, 0x1, 0xc3, 0x320978, 0xd), at 0x15268
[12] main(0x29334, 0xefffff1c, 0x2d0b8, 0x0, 0x0, 0x0), at 0x16734

Workaround

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.

Resolution

This issue is addressed in the following releases:

SPARC Platform

• Solaris 2.6 with patch 105401-44 or later
• Solaris 7 with patch 106942-27 or later
• Solaris 8 with patch 108993-18 or later
• Solaris 9 with patch 113319-11 or later

x86 Platform

• Solaris 2.6 with patch 105402-44 or later
• Solaris 7 with patch 106943-27 or later
• Solaris 8 with patch 108994-18 or later
• Solaris 9 with patch 113719-04 or later

Modification History
Date: 26-MAR-2003

• Updated Relief/Workaround with Temporary patches

Date: 28-APR-2003

• Updated Contributing Factors, Relief/Workaround and Resolution sections

Date: 08-MAY-2003

• Updated Contributing Factors and Resolution sections

References

105401-44
108993-18
113319-11
105402-44
106943-27
108994-18
113719-04
106942-27




Attachments

This solution has no attachment