SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Generic)  >   Platform LSF Vendors:   Platform Computing Inc.
(Vendor Responds) Re: Platform Computing's Platform LSF Load Sharing Application Contains Multiple Flaws, Disclosing Files to Local Users, Giving Local Users Root Access, and Crashing When Remote Users Send Malformed Packets
SecurityTracker Alert ID:  1002925
SecurityTracker URL:  http://securitytracker.com/id/1002925
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 8 2001
Impact:   Denial of service via network, Disclosure of system information, Disclosure of user information, Execution of arbitrary code via local system, Modification of system information, Modification of user information, Root access via local system
Vendor Confirmed:  Yes  
Version(s): 4.0
Description:   Several vulnerabilities have been reported in Platform Computing's Platform LSF load sharing facility software. These flaws include buffer overflows and unsafe use of temporary files.

A local user can read any file on the system in the default configuration due to the lack of file and symlink checking when writing to log files. A local user can create a symlink from a log file name in the /tmp directory. When LSF starts, LSF will append its log entries to the symlinked file and will change the permissions of the symlinked file to allow global read privileges.

An example symlink to allow all local users to read the /etc/shadow file is:

ln -s /etc/shadow /tmp/lim.log.hostname

Local users can also read any file on the system using another method. Because a user is given their own configuration file, the user can force some of LSF applications to do unexpected things. An example of how a symlink attack can be used in conjunction with configuration file modifications to allow a local user to read any file on the system (/etc/shadow in this example) is shown:

Change the LSF_ENVDIR so it will point to your home directory:
% setenv LSF_ENVDIR /my/home/dir

Copy LSF configuration file to your home directory:
% cp /etc/lsf.conf /my/home/dir/lsf.conf

Do the following changes in the /my/home/dir/lsf.conf:
LSB_CMD_LOGDIR=/tmp/test
LSF_LOGDIR=/tmp/test

Make a /tmp/test directory:
% mkdir /tmp/test

Do a sym-link from LSF log file to /etc/shadow:
% ln -s /etc/shadow /tmp/test/bqc.log.hostname
[ 'hostname' is your hostname ]

At this point, the user must force an LSF application that has set user id (suid) root privileges to write an entry to the log file bqc.log.hostname. 'bqc' is an appropriate application to do this and can be asked for information on a non-existent queue (dupa_zbita):

% bqc -i dupa_zbita

This will cause 'bqc' to write to its log file. Because of the user's own configuration file (/my/home/dir/lsf.conf) and the symlink, the log entry will be written to /etc/shadow and the permissions of /etc/shadow will be changed to world readable permissions.

It is reported that the 'lsadmin' and 'badmin' executables contain several exploitable buffer overflows that allow a local user to execute arbitrary code with root level privileges (as those executables have suid root permissions). The buffer overflow can be demonstrated with the following commands, which will cause a segmentation fault:

% setenv LSF_ENVDIR `perl -e 'print "A" x 292'`
% lsadmin [or badmin]

It is reported that there are other buffer overflow vulnerability in other executables.

A remote user can reportedly exploit a buffer overflow in the 'mbatchd' daemon to cause it to crash by sending specially crafted packets to the daemon. A demonstration exploit transcript is provided:

% bstatus -d AAA -J `perl -e 'print "A" x 500'`
Job <0>: XDR encode/decode error
% bjobs
batch system daemon not responding ... still trying

% tail -2 sbatchd.log.hostanme
17:18:37 2001 87317 3 4.0.1 mbatchd died with signal <11>
termination
17:18:37 2001 87317 3 4.0.1 mbatchd core dumped

[Editor's note: The author indicates that it may be possible to execute arbitrary code via this method, but that possibility is not explored in the author's report.]

The vendor has reportedly been notified.

Impact:   A local user can read any file on the system and can execute arbitrary code on the system with root level privileges. A remote user can cause the mbatchd daemon to crash.
Solution:   The vendor has reportedly been collaborating closely with the author of the original report to better understand the issues raised and to provide a timely solution. Patches are currently being developed.

The vendor has provided the following information:

"o Permission setting on LSF error log

If you are using the default LSF 4.2 installation, you would not have any exposure because the LSF error log directory can only be written by root or the LSF administrator.

If you are using syslog or if error log is in a directory that is writeable only by root, you would not be exposed.

You can check the permission of your LSF error log directory (LSF_LOGDIR parameter in the lsf.conf) to make sure it is not writable by regular users.

o setuid binaries

In an LSF installation configured with Kerberos, there are only two setuid binaries, lsadmin and badmin, which are administrator commands. You can unset the setuid bits for these two binaries, and run these commands as root to perform administration operation.

A patch will address the setuid issues raised in the posting.

o Buffer overflows

We are doing a thorough investigation into all sources of buffer overflows.

Updates to our progress will be posted when available."

Vendor URL:  www.platform.com/products/wm/LSF/index.asp (Links to External Site)
Cause:   Access control error, Boundary error, State error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry is a follow-up to the message listed below.
Dec 5 2001 Platform Computing's Platform LSF Load Sharing Application Contains Multiple Flaws, Disclosing Files to Local Users, Giving Local Users Root Access, and Crashing When Remote Users Send Malformed Packets



 Source Message Contents

Subject:  Re: Many vulnerabilities in LSF 4.0



In-Reply-To: <Pine.LNX.4.10.10112051714250.19966-100000@apollo.aci.com.pl>


Since the initial posting on Dec 5, we have been collaborating closely with the author to
better understand the issues raised and we are wotking with him to provide a timely 
solution.  Our product teams are working on patches.

The issues can be broken down into three areas:

o Permission setting on LSF error log

   If you are using the default LSF 4.2 installation, you would not have any exposure 
   because the LSF error log directory can only be written by root or the LSF
   administrator.

   If you are using syslog or if error log is in a directory that is writeable only by root, you
   would not be exposed.

   You can check the permission of your LSF error log directory (LSF_LOGDIR
   parameter in the lsf.conf) to make sure it is not writable by regular users.

o setuid binaries

   In an LSF installation configured with Kerberos, there are only two setuid binaries, 
   lsadmin and badmin, which are administrator commands.  You can unset the setuid
   bits for these two binaries, and run these commands as root to perform administration
   operation.

   A patch will address the setuid issues raised in the posting.

o Buffer overflows

  We are doing a thorough investigation into all sources of buffer overflows.


Updates to our progress will be posted when available.

take care,

Greg

Greg L. Reid                                        greid@platform.com
Second-line Technical Support
Platform Computing Corporation
3760 14th Avenue, Markham               Phone:(905)948-4207
Ontario, Canada, L3R 3T7                  Cell :(416)788-4487

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC