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...
This archive was generated by hypermail 2b30 : Wed Dec 05 2001 - 13:32:16 PST