Many vulnerabilities in LSF 4.0

[Tomasz Grabowski <cadence () apollo aci com pl>]

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...