Note: This is an archival copy of Security Sun Alert 252787 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1020130.1.
Solaris 8 Operating System
Solaris 9 Operating System
Solaris 10 Operating System
Date of Resolved Release
A Security Vulnerability in Solaris Kerberos Credential Management May Lead to Unauthorized Access of Kerberized NFS Mount Points
A security vulnerability in the Solaris Kerberos (see kerberos(5)) credential cache management may allow a local unprivileged user to access Kerberized mount points without authorization.
Sun acknowledges with thanks, Anton Lundin for bringing this issue to our attention.
2. Contributing Factors
This issue can occur in the following releases:
1. Solaris 8 entered EOSL Phase 2 on 1 April 2009. Entitlement to patches developed on or after 1 April 2009 requires the purchase of the Solaris 8 Vintage Patch Service. See note in section 5 for more details.
2. OpenSolaris distributions may include additional bug fixes above and beyond the build from which it was derived. The base build can be derived as follows:
$ uname -v3. This issue could affect all systems utilizing Kerberized NFS mount points as an NFS client. To determine if a system could be exposed to this issue, the following command can be run:
$ nfsstat -m | grep sec=krbIf any data is returned, the system may be vulnerable to this issue.
This issue exists on all systems utilizing Kerberized NFS mount points. There are no predictable symptoms that would indicate this issue has been exploited to gain unauthorized access to Kerberized NFS shares.
There is no workaround that would prevent unauthorized access to affected shares. It may be desirable therefore to modify the share and mount options so that they no longer utilize Kerberos. This can be done by editing of the dfstab(4) file on the NFS server and removing the 'sec=' option.
Alternatively, the unshare(1) command can be used to unshare the filesystem, and the share(1) command to share the filesystem, not specifying the 'sec=' option. The client systems could then umount(1) the filesystem and then mount(1) with no 'sec=' option. This will allow UNIX system permissions to safeguard against unauthorized access.
Note: As this workaround disables Kerberos for the affected NFS shares, the security of those shares may be impacted in various ways depending on the configuration. For example, network traffic associated with those shares may no longer be encrypted during transfer, and the access permissions will revert to those supported by the standard UNIX permissions implementation.
This issue is addressed in the following releases:
If this issue has occurred, messages such as the following will be seen in the patch install log (for example "/var/sadm/patch/140074-05/log") after installation of the patch, or in the manifest import service's log files "/var/svc/log/system-manifest-import:default.log" or "/etc/svc/volatile/system-manifest-import:default.log":
'svccfg: Conflict upgrading svc:/network/rpc/gss (property "inetd_start/privileges" has different values).'
To work around this issue, the customized version of the service can be deleted and replaced with the version from the resolution using commands such as the following:
# svcadm disable svc:/network/rpc/gss:default
# svccfg delete svc:/network/rpc/gss
# svccfg import /var/svc/manifest/network/rpc/gss.xml
# svcadm enable svc:/network/rpc/gss:defaultThis issue does not apply to the Solaris 8 and 9 resolutions as they do not use SMF.
Note 2: The READMEs of Solaris 8 patches developed on or after 1 April 2009 are available to all customers. However, Solaris 8 entered EOSL Phase 2 on April 1, 2009 and thus entitlement for these patches, including those that fix security vulnerabilities, requires the purchase of the Solaris 8 Vintage Patch Service. More information about the Solaris 8 Vintage Patch Service is available at: on Security Sun Alerts, see 1009886.1.
Copyright 2000-2009 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved.
29-Jul-2009: Updated Resolution section
This solution has no attachment