7626043 2001-12-05 17:44 +0100 /238 rader/ Tomasz Grabowski <cadence@apollo.aci.com.pl>
Sänt av: joel@lysator.liu.se
Importerad: 2001-12-05 22:33 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: cvarela@platform.com
Mottagare: Bugtraq (import) <20037>
Ärende: Many vulnerabilities in LSF 4.0
------------------------------------------------------------
From: Tomasz Grabowski <cadence@apollo.aci.com.pl>
To: bugtraq@securityfocus.com
Cc: cvarela@platform.com
Message-ID: <Pine.LNX.4.10.10112051714250.19966-100000@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...
(7626043) /Tomasz Grabowski <cadence@apollo.aci.com.pl>/(Ombruten)