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.