|
COMMAND LSF SYSTEMS AFFECTED Tested on : LSF version 4 OS : IRIX & Linux PROBLEM Tomasz Grabowski reported following bugs & exploits, on LSF. Load Sharing 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. 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. 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... 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. SOLUTION Update ====== Patch is available for customers from ftp.platform.com or by contacting Technical Support (support@platform.com). The patch is currently available for LSF 4.2 on all major platforms. Patches for other platforms and versions of LSF will be made available as required. WORKAROUNDS =========== Vulnerability #1 ================ 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. 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). Update ====== greid@platform.com (Greg Reid) says : o Permission setting on LSF error log If you are using the default LSF 4.2 installation, you would not have any exposure because the LSF error log directory can only be written by root or the LSF administrator. If you are using syslog or if error log is in a directory that is writeable only by root, you would not be exposed. You can check the permission of your LSF error log directory (LSF_LOGDIR parameter in the lsf.conf) to make sure it is not writable by regular users. o setuid binaries In an LSF installation configured with Kerberos, there are only two setuid binaries, lsadmin and badmin, which are administrator commands. You can unset the setuid bits for these two binaries, and run these commands as root to perform administration operation. A patch will address the setuid issues raised in the posting. o Buffer overflows We are doing a thorough investigation into all sources of buffer overflows.