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.
Article ID : 1001028.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2006-08-29
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

Privileged Applications Linked to libpkcs11(3LIB) Which Obtain Password Entries Using getpwnam(3C) May Fail or Possibly Grant Elevated Privileges to Local Users



Category
Security

Release Phase
Resolved

Product
Solaris 10 Operating System

Bug Id
6372587

Date of Resolved Release
24-APR-2006

Impact

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.


Contributing Factors

This issue can occur in the following releases:

SPARC Platform

  • Solaris 10 without patch 118918-14 [Global]
  • Solaris 10 without patch 118562-09 [Restricted]

x86 Platform

  • Solaris 10 without patch 118919-12 [Global]
  • Solaris 10 without patch 118563-07 [Restricted]

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
    [68]    | 134548064|       0|FUNC |GLOB |0    |UNDEF  |getpwnam
    [49]    | 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().


Symptoms

There are no reliable symptoms that would show if this issue has been exploited to execute arbitrary commands with elevated privileges on a system.


Workaround

There is no workaround. Please see the "Resolution" section below.


Resolution

This issue is addressed in the following releases:

SPARC Platform

  • Solaris 10 with patch 118918-14 or later [Global]
  • Solaris 10 with patch 118562-09 or later [Restricted]

x86 Platform

  • Solaris 10 with patch 118919-12 or later [Global]
  • Solaris 10 with patch 118563-07 or later [Restricted]


References

118918-14
118919-12




Attachments
This solution has no attachment