Vulnerability Note VU#683673

Sun Solaris priocntl(2) does not adequately validate path to kernel modules that implement lightweight process (LWP) scheduling policy

Original Release date: 04 Dec 2002 | Last revised: 06 Dec 2002

Overview

The Sun Solaris priocntl(2) function does not adequately validate a memory structure that specifies the name of a kernel module. As a result, a local attacker could execute arbitrary code with superuser privileges on a vulnerable system.

Description

The Sun Solaris priocntl(2) function provides the ability to control the scheduling of lightweight processes (LWPs). LWPs are grouped into several classes, each class having a different scheduling policy. The priocntl(2) command PC_GETCID can be used to get the class ID and attributes for a class of LWPs. The PC_GETCID command can take as an argument a pointer to a structure of type pcinfo_t that contains information about the class. A pcinfo_t structure includes a member called pc_clname that specifies the name of the class, and in certain cases, the name of a kernel module that implements the process scheduling policy for the class. priocntl(2) searches for the kernel module specified by pc_clname in /kernel/sched and /usr/kernel/sched.

priocntl(2) does not adequately validate the data in pc_clname. As demonstrated by the exploit code posted to the BugTraq mailing list, an attacker with local user privileges can:

  1. create an arbitrary kernel module and place it in a writable location (/tmp/module for instance),
  2. create an arbitrary pcinfo_t structure with pc_clname set to the location of the kernel module relative to /usr/kernel/sched (../../../tmp/module), and
  3. issue a priocntl(2) call using the PC_GETCID command and a pointer to the pcinfo_t structure created by the attacker.
Since priocntl(2) accepts the relative path operators (../) in pc_clname, the attacker-supplied module will be loaded by the kernel, and the attacker can act with superuser privileges.

A different aspect of this vulnerability is that priocntl(2) does not validate or authenticate the kernel module that is being loaded. A message posted to BugTraq suggests checking the permissions ownership of the module and its parent directories. Another option could be to check a cryptographic hash or signature before loading a module.

Impact

A local attacker could execute code with superuser privileges.

Solution


Apply Patch or Upgrade

Sun Alert ID 49131 states that "A final resolution is pending completion."


Change Location of /sched Directories

Sun Alert ID 49131 includes a workaround that involves nesting the /sched directories deeply enough that they cannot be traversed in the space available in pc_clname.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Sun Microsystems Inc.Affected02 Dec 200205 Dec 2002
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

Credit

This vulnerability was publicly reported by CatDog.

This document was written by Art Manion.

Other Information

  • CVE IDs: CAN-2002-1296
  • Date Public: 27 Nov 2002
  • Date First Published: 04 Dec 2002
  • Date Last Updated: 06 Dec 2002
  • Severity Metric: 20.48
  • Document Revision: 42

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.