[UNIX] LSF Contains Multiple Security Vulnerabilities
From: support@securiteam.comDate: 12/12/01
- Previous message: support@securiteam.com: "[NT] Microsoft Outlook Express 6 "E-mail Attachment Security" Flawed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Wed, 12 Dec 2001 15:35:00 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
LSF Contains Multiple Security Vulnerabilities
------------------------------------------------------------------------
SUMMARY
Load Sharing Facility from <http://www.platform.com/> Platform is a suite
of application resource management products that schedule, monitor and
analyze the workload for a network of computers. Multiple security
vulnerabilities have been found in the product that may result in local
users being able to read restricted system files and possibly obtaining
root access.
DETAILS
Vulnerable systems:
LSF version 4.0
Vulnerability #1:
A problem with insecure default log configuration result in attackers
being able to read any file on the system.
In default LSF configuration, all LSF logs are kept in the /tmp directory.
The problem is that programs that write to these log files are working
with root privileges. Moreover, they actually do not do any checking about
that log files. Therefore, attacker is able, by making a 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 that 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 us say,
/tmp/lsf.log directory. Of course, only root should have write access to
the /tmp/lsf.log directory.
Vulnerability #2:
The problem is correlated with fact that any user can have a configuration
file. The result is that attackers can read any file on system.
The fact that users can have own customized configuration 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 the LSF configuration file to your home directory:
% cp /etc/lsf.conf /my/home/dir/lsf.conf
Do the following changes in /my/home/dir/lsf.conf:
LSB_CMD_LOGDIR=/tmp/test
LSF_LOGDIR=/tmp/test
Make a /tmp/test directory:
% mkdir /tmp/test
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. Therefore,
'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 non_existent
'bqc' will find out that the queue "non_existent" does not exist and it
will happily send it to its log file. It will use our own configuration
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.
Vulnerability #3:
Flaws in "lsadmin" and "badmin" executables. This enables attackers to
gain root privileges.
'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.
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
Vulnerability #4:
When using an authentication scheme other than 'eauth' attackers can gain
root privileges.
If we are not using 'eauth' as an authentication mechanism all LSF
executables are installed with suid=root. The problem is that there are
plenty of buffer overflows in these executables.
Example:
% bstatus `perl -e 'print "A" x 524'`
[You may need more than 524]
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 the '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.
Note: when you 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.
The 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 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:
A flaw in 'mbatchd' daemon leads to remote buffer overflow.
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.
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
ADDITIONAL INFORMATION
The information has been provided by <mailto:cadence@apollo.aci.com.pl>
Tomasz Grabowski.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NT] Microsoft Outlook Express 6 "E-mail Attachment Security" Flawed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
