Patches are now available for Solaris 8 which resolve this bug.
This issue is addressed in the following releases:
SPARC
* Solaris 8 with patch 108528-18 or later
Intel
* Solaris 8 with patch 108529-18 or later
Both are available from http://sunsolve.sun.com/ for both contract and
non-contract customers.
Patches for Solaris 2.6, 7 and 9 will follow shortly.
Further details are available in Sun Alert 49131, available at
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F49131
Scott
On Wed, Nov 27, 2002 at 11:00:11AM +0800, ÝþÒãÁ? wrote:
> ** Moderator note:
>
> Messages with links to technical details outside of the message are not approved.
> Because of the potential delay waiting for another submission, the original message
> has been modified to include the details.
>
> Details follow:
>
> Solaris's Got Big problem on System Call priocntl()
>
> Description
> syscall priocntl(2) is used as process scheduler control
> it's declared as below:
>
> long priocntl(idtype_t idtype, id_t id, int cmd, /* arg */ ...);
>
> while set 'cmd' arg to PC_GETCID, priocntl()'s function is like below
> (see ManPage 'man -s 2 priocntl')
> "Get class ID and class attributes for a specific class
> given class name. The idtype and id arguments are
> ignored. If arg is non-null, it points to a structure
> of type pcinfo_t. The pc_clname buffer contains the
> name of the class whose attributes you are getting."
>
> as it said, pc_clname points to a string specify the module.
> priocntl() will load the module without any privilege check.
> The module's name is a relative path, priocntl will search the module file
> in only /kernel/sched and /usr/kernel/sched/ dirs.
> but unfortunately, priocntl() never check '../' in pc_clname arg
> we can use '../../../tmp/module' to make priocntl() load a module from anywhere
[..snip...]
This archive was generated by hypermail 2b30 : Fri Dec 27 2002 - 09:54:58 PST