================================================================================
Multiple IBM Spectrum LSF Authentication Vulnerabilities (Eauth) - CVE-2020-4983
================================================================================

* Software: Spectrum LSF
* Vendor: IBM
* Affected Versions: 10.1/10.2 (Other versions are also likely affected)
* CVE: CVE-2020-4983
* Severity: CVSS 9.6 (Critical) [AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H]
* Author: John Fitzpatrick (HPCsec)
* Date: 2021-01-14


Description
===========

This advisory details two closely related vulnerabilities affecting versions of Spectrum LSF which can allow an adversary to gain root access to a cluster.
 
This vulnerability affects, and (at the time of publication) remains unpatched in the Community Edition of LSF. This vulnerability has also been identified within other branches of LSF, although IBM refute this despite documenting it as a feature of LSF within their own documentation: https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_admin/ext_auth_kerb_lsf_about.html. Therefore, in order to provide clarity, this advisory contains details on how to identify the vulnerability on a system. Clusters using kerberos for LSF authentication (non-default) are not believed to be affected.


Issue#1 IBM LSF Hardcoded Eauth Key
===================================

The key which the “eauth” authentication mechanism within LSF uses for authentication is hardcoded into the binary and therefore shared by all LSF installations. By default this key is the sole mechanism used in order to authenticate users and is accessible to anyone with a copy of LSF. The community edition of LSF is freely downloadable and also uses this same key. Any adversary with access to a key is able to impersonate other users of the system.


Issue#2 IBM LSF Eauth Key Exposure
==================================

By default LSF uses eauth as a means to authenticate users, generating an authentication token for them based upon their username and some key material. However, eauth does not safely validate that the user requesting an authentication token is the user for whom the authentication token is valid. As a result it is possible for any user to obtain authentication tokens for any other user of the LSF cluster (including for root).


Determining Vulnerability
=========================

It is possible to check whether an installation is making use of the shared hardcoded eauth key by simply running the following command (as root) within your LSF installation:

     # eauth -c hpcsec

If the following output is displayed then the installation is making use of the hardcoded eauth key and is therefore vulnerable to the “IBM LSF Hardcoded Eauth Key” issue:

     #)**.-0!/&0(0&$$

To check more comprehensively for both issues you can download a script to check from here:
     https://files.hpcsec.com/utilities/check-cve-2020-4983.py


HPCsec Recommended Solution
===========================

LSF provides a mechanism that can be leveraged to resolve these vulnerabilities without the need to apply any patches. This involves configuring LSF to make use of an alternate key and also configuring the use of eauth (which accesses the key) in such a way that it cannot be manipulated by a user. The process for doing this is as follows:

1) Create a file "/etc/lsf.sudoers"

2) Enter the following in this file, obviously replacing the placeholder with a key:
     "LSF_EAUTH_KEY=<enter a long complex key here>"

3) Ensure that only root can read this file as it contains the key
     chown root:root /etc/lsf.sudoers
     chmod 600 /etc/lsf.sudoers

4) In order to prevent users from manipulating the execution of eauth whilst allowing it to read the lsf.sudoers file eauth must be configured to be setUID root:
     chown root:root eauth 
     chmod 4711 eauth

The steps above will need to be followed on every node that forms part of the LSF cluster as each node must be using the same key.

You can also further enhance the security of LSF by utilising an alternate version of eauth will also limit the opportunity for LSF messages to be replayed. This can be done by replacing the version of eauth in use with the version named eauth.cve (which can be found in the same directory as eauth). If this has been done then running the command “eauth -c hpcsec” will give output similar (but different) to the output below:

     $ eauth.cve -c hpcsec
     :<=7463?<;5::=>7@95@61<55:2:?56=

IBM has provided multiple updates relating to these issues since they were first identified in 2017. However, the release notes and IBM advisories do not appear to actually resolve the issues. Whilst we do recommend installing the IBM security updates they should be installed under the assumption that they are ineffective against this issue. 

IBM have also stated that the updates for the community edition have not been released yet as it lags behind the other editions.

For reference IBM advisories on this issue are listed below:

[Security Bulletin: Privilege Escalation / User Impersonation affects IBM Platform LSF and IBM Spectrum LSF]
https://www.ibm.com/support/pages/node/630961

[IBM Platform LSF 9.1.3 Fix 445809]
https://delivery04.dhe.ibm.com/sar/CMA/OSA/06u01/0/Readme_build445809unix.html

[External authentication with IBM Spectrum LSF (eauth)]
https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_admin/ext_auth_kerb_lsf_about.html

[10.1 Fix Pack 7]
https://www.ibm.com/support/knowledgecenter/SSWRJV_10.1.0/lsf_release_notes/lsf_relnotes_security10.1.0.7.html

[Latest IBM advisory notice on this issue]
https://www.ibm.com/support/pages/node/6395478

[IBM Spectrum LSF 10.1 Fix 564668 Readme File]
https://delivery04.dhe.ibm.com/sar/CMA/OSA/09e8q/0/Readme_BUILD564668.html


Other references and Timeline
=============================

These issues were first reported to IBM in 2017, a copy of the original advisory can be found here:
     https://www.hpcsec.com/2018/03/16/ibm-spectrum-lsf-privilege-escalation/

2020-08-17: Vulnerabilities re-reported to IBM by HPCsec
2020-09-03: IBM close issue stating that it is a non-issue as it has been previously fixed 
2020-12-23: IBM silently publish a “fix” for this issue
2020-01-04: IBM advisory updated to acknowledge HPCsec’s work and assign a CVE
2020-01-14: HPCsec advisory published

=======================================================================
The original and maintained version of this advisory can be found here:
https://www.hpcsec.com/2020/01/14/cve-2020-4983/
=======================================================================