|
|
|
|
| |
| Load Sharing Facility from 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. |
| |
Credit:
The information has been provided by Tomasz Grabowski.
|
| |
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
|
|
|
|
|
|
|
