[23431] in bugtraq
Re: Many vulnerabilities in LSF 4.0
daemon@ATHENA.MIT.EDU (Greg Reid)
Fri Dec 7 19:10:24 2001
Date: 7 Dec 2001 11:40:48 -0000
Message-ID: <20011207114048.1027.qmail@mail.securityfocus.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
From: Greg Reid <greid@platform.com>
To: bugtraq@securityfocus.com
In-Reply-To: <Pine.LNX.4.10.10112051714250.19966-100000@apollo.aci.com.pl>
Since the initial posting on Dec 5, we have been collaborating closely with the author to
better understand the issues raised and we are wotking with him to provide a timely
solution. Our product teams are working on patches.
The issues can be broken down into three areas:
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.
Updates to our progress will be posted when available.
take care,
Greg
Greg L. Reid greid@platform.com
Second-line Technical Support
Platform Computing Corporation
3760 14th Avenue, Markham Phone:(905)948-4207
Ontario, Canada, L3R 3T7 Cell :(416)788-4487
