Note: This is an archival copy of Security Sun Alert 201355 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1001028.1.
Solaris 10 Operating System
Date of Resolved Release
If a privileged application links to the libpkcs11(3LIB) library and utilizes the getpwnam(3C) family of non-reentrant functions to obtain password entries, then it may be possible for a local unprivileged user to execute arbitrary code with the privileges of the application depending on the way the application uses data provided by getpwnam(3C) and related functions. The application may also fail due to receiving unexpected data from one of the non-reentrant getpwnam(3C) functions.
This issue can occur in the following releases:
Note: Solaris 8 and Solaris 9 are not affected by this issue.
To determine if an application links to the libpkcs11(3LIB) library the ldd(1) command can be used:
$ ldd /usr/sbin/in.telnetd | grep pkcs11 libpkcs11.so.1 => /usr/lib/libpkcs11.so.1
To determine if an application utilizes one of the getpwnam(3C) family of non-reentrant functions, the nm(1) command may work if the application binary has not been stripped using strip(1). The file(1) command will report if a binary has been stripped. If it hasn't, then nm(1) can be used to look for the getpwnam(3C) functions:
$ file /bin/id /bin/id: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available $ nm /bin/id |grep getpw  | 134548064| 0|FUNC |GLOB |0 |UNDEF |getpwnam  | 134548272| 0|FUNC |GLOB |0 |UNDEF |getpwuid
Alternatively, the truss(1) utility can be used to determine if an application calls one of the getpwnam(3C) non-reentrant functions:
$ truss -f -t\!all -ulibc:*getpw*: /bin/id 5999/1@1: -> libc:getpwuid(0x17fa6) 5999/1@1: <- libc:getpwuid() = 0x80637a4
Note: This issue does not affect applications which utilize the reentrant interfaces for the getpwnam(3C) functions: getpwnam_r(), getpwuid_r(), getpwent_r(), and fgetpwent_r().
There are no reliable symptoms that would show if this issue has been exploited to execute arbitrary commands with elevated privileges on a system.
There is no workaround. Please see the "Resolution" section below.
This issue is addressed in the following releases:
This solution has no attachment