Product
Solaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System

Bug Id
4613875

Date of Resolved Release
13-OCT-2007

Impact

A security vulnerability in the Solaris RPC services library (librpcsvc(3LIB)) may allow a local unprivileged user to crash the automountd(1M) daemon on a system if the user invokes the automountd(1M) service to access a remote NFS server which exports a large number of file systems.

This vulnerability may also allow a remote unprivileged user to crash the mountd(1M) service on an NFS server which exports a large number of file systems. This would prevent further access to the NFS shares on NFS client systems.

The ability to crash the automountd(1M) and the mountd(1M) services is a type of Denial of Service against networked file systems.

Contributing Factors

This issue can occur in the following releases:

SPARC Platform

• Solaris 8 without patch 127548-01
• Solaris 9 without patch 123396-01
• Solaris 10 without patch 124444-01

x86 Platform

• Solaris 8 without patch 127549-01
• Solaris 9 without patch 123397-01
• Solaris 10 without patch 124445-01

Note 1: For the first issue described above, which may lead to a Denial of Service (DoS) to the automountd(1M) process, only systems which have automatic mount points installed for hosts which are NFS servers exporting a large number of file systems are affected.

The automountd(1M) service must be enabled on the system for this issue to be exploited. To determine if a Solaris 8 or Solaris 9 system has the automountd(1M) service enabled, the following command can be used:

    $ ps -ef | grep automountd
    root  3676     1  0   Aug 13 ?    169:36 /usr/lib/autofs/automountd

On a Solaris 10 host, the svcs(1) command can be used to determine if the automountd(1M) service is running:

    $ svcs svc:/system/filesystem/autofs
    STATE          STIME    FMRI
    online         Jul_14   svc:/system/filesystem/autofs:default

To determine if the system has automatic mount points installed for hosts running NFS services, check the "/etc/auto_master" file to see if there is an entry called "-hosts" in the file. This may be done using the grep(1) utility as follows:

    $ grep -- -hosts /etc/auto_master || echo "Automatic mount points not installed"
    /net        -hosts       -nosuid,nobrowse

Note 2: For the second issue described above, which may lead to a remote denial of service to the mountd(1M) process, only systems which are NFS servers exporting a large number of file systems or exporting a file system using long access lists are affected. For an access list description see share_nfs(1M).

The mountd(1M) service must be enabled on this system for this issue to be exploited. To determine if a Solaris 8 or Solaris 9 system has the mountd(1M) service enabled, the following command can be used:

    $ pgrep -lx mountd
    419 mountd

On a Solaris 10 host, the svcs(1) command can be used to determine if the mountd(1M) service is running:

    $ svcs svc:/network/nfs/server:default
    STATE          STIME    FMRI
    online         Jul_31   svc:/network/nfs/server:default

To determine how many file systems are exported, the following command can be used:

    $ wc -l /etc/dfs/sharetab

To determine the number of components in each access list, a command such as the following can be used:

    $ while read line; do (echo $line | tr -d -c ':' | wc -c); done </etc/dfs/sharetab

If the number of shared file systems or the length of the access lists are greater than 2630, then the described issue may occur.

Symptoms

The following symptoms may be observed if the first issue is exploited to cause a Denial of Service (DoS) to automountd(1M):

Users may notice that processes accessing autofs(4) mount points become unresponsive and hang. On Solaris 8, Solaris 9 and Solaris 10 systems, messages similar to the following are printed on the console and are logged by the syslogd(1M) daemon:

    Sep  7 08:50:20 client1 autofs: automountd not running, retrying

On Solaris 10 systems, messages similar to the following are also printed on the console and are logged by the syslogd(1M) daemon:

    Sep 12 02:04:12 client1 svc.startd[7]: system/filesystem/autofs:default
    failed repeatedly: transitioned to maintenance (see 'svcs -xv' for details)

The automountd(1M) service may crash with a stack trace similar to the following:

    ff2a31ac xdr_reference (b1bd4, 144ea8, c, ff384898, 81010100, ff00) + 84
    ff299418 xdr_pointer (b1bd4, 144ea8, c, ff384898, 0, 0) + 5c
    ff384880 xdr_exports (b1bd4, 144ea8, 0, 0, 0, 1235b7) + 20
    ff3848e0 xdr_exportnode (b1bd4, 144ea0, ffffffff, 0, 0, 0) + 48

The automountd(1M) service stops running on the system if this issue has been exploited. This can be verified by using the following command:

    $ ps -ef | grep automountd

The following symptoms may be observed if the second issue is exploited to cause a Denial of Service (DoS) to mountd(1M):

The mountd(1M) service may crash with a stack trace similar to the following:

    ff2a31ac xdr_reference (b1bd4, 144ea8, c, ff384898, 81010100, ff00) + 84
    ff299418 xdr_pointer (b1bd4, 144ea8, c, ff384898, 0, 0) + 5c
    ff384880 xdr_exports (b1bd4, 144ea8, 0, 0, 0, 1235b7) + 20
    ff3848e0 xdr_exportnode (b1bd4, 144ea0, ffffffff, 0, 0, 0) + 48

Or:

    ff2a2b34 xdr_reference (ac92c, 13126c, 8, ff38481c, 81010100, ff00) + 84
    ff298dcc xdr_pointer (ac92c, 13126c, 8, ff38481c, 0, 0) + 5c
    ff384804 xdr_groups (ac92c, 13126c, 0, 0, 6d, 9632c) + 20
    ff384848 xdr_groupnode (ac92c, 131268, ffffffff, 0, 0, 0) + 2c

The mountd(1M) service stops running on the system if this issue has been exploited. This can be verified using the following command:

    $ ps -ef | grep mountd

 

Workaround

For the automountd(1M) issue:

Until the patches can be applied, it may be possible to work around the automountd(1M) crash issue by removing or commenting the "-hosts" entry in the "/etc/auto_master" file and by restarting the automountd(1M) service.

The following command may be run as the root user to restart the automountd(1M) service on Solaris 8 and Solaris 9 systems:

    # /etc/init.d/autofs start

The following command may be run as the root user to restart the automountd(1M) service on Solaris 10 systems:

    # svcadm restart svc:/system/filesystem/autofs

If "svc:/system/filesystem/autofs" is in maintenance state, use following:

    # svcadm clear svc:/system/filesystem/autofs
    # svcadm enable svc:/system/filesystem/autofs

Following this change, all mount points in the "/net" directory must be unmounted using the automount(1M) utility. If the automount(1M) utility cannot unmount any of the mount points in the "/net" directory, the system must be rebooted after modifying the "/etc/auto_master" file.

Note: Deploying this workaround disables user access to remote hosts that are running the NFS service.

For the mountd(1M) issue:

To work around the issue that allows an unprivileged user to crash the mountd(1M) service on a remote NFS server, reduce the number of shared file systems on the remote NFS server and restart the NFS service on that NFS server.

To reduce the number of shared file systems, check what file systems are exported by looking in "/etc/dfs/sharetab" and remove or comment entries in "/etc/dfs/dfstab".

The following command may be run as the root user to restart the NFS service on Solaris 8 and Solaris 9 systems:

    # /etc/init.d/nfs.server stop
    # /etc/init.d/nfs.server start

The following command may be run as the root user to restart the NFS service on Solaris 10 systems:

    # svcadm restart svc:/network/nfs/server:default

 

Resolution

This issue is addressed in the following releases:

SPARC Platform

• Solaris 8 with patch 127548-01 or later
• Solaris 9 with patch 123396-01 or later
• Solaris 10 with patch 124444-01 or later

x86 Platform

• Solaris 8 with patch 127549-01 or later
• Solaris 9 with patch 123397-01 or later
• Solaris 10 with patch 124445-01 or later

References

124444-01
124445-01
127548-01
127549-01
123396-01
123397-01




Attachments

This solution has no attachment