exploit the possibilities

IBM Spectrum LSF 10.1 / 10.2 Hardcoded Eauth Key / Eauth Key Exposure

IBM Spectrum LSF 10.1 / 10.2 Hardcoded Eauth Key / Eauth Key Exposure
Posted Jan 18, 2021
Authored by John Fitzpatrick

IBM Spectrum LSF versions 10.1 and 10.2 suffer from hardcoded eauth key and eauth key exposure vulnerabilities.

tags | advisory, vulnerability
advisories | CVE-2020-4983
MD5 | 65c67bbfe71af2731bd4de95c90a4a57

IBM Spectrum LSF 10.1 / 10.2 Hardcoded Eauth Key / Eauth Key Exposure

Change Mirror Download
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


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:


To check more comprehensively for both issues you can download a script to check from here:

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

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]

[IBM Platform LSF 9.1.3 Fix 445809]

[External authentication with IBM Spectrum LSF (eauth)]

[10.1 Fix Pack 7]

[Latest IBM advisory notice on this issue]

[IBM Spectrum LSF 10.1 Fix 564668 Readme File]

Other references and Timeline

These issues were first reported to IBM in 2017, a copy of the original advisory can be found here:

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:

Login or Register to add favorites

File Archive:

March 2021

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    19 Files
  • 2
    Mar 2nd
    15 Files
  • 3
    Mar 3rd
    30 Files
  • 4
    Mar 4th
    13 Files
  • 5
    Mar 5th
    9 Files
  • 6
    Mar 6th
    0 Files
  • 7
    Mar 7th
    0 Files
  • 8
    Mar 8th
    0 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    0 Files
  • 12
    Mar 12th
    0 Files
  • 13
    Mar 13th
    0 Files
  • 14
    Mar 14th
    0 Files
  • 15
    Mar 15th
    0 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    0 Files
  • 19
    Mar 19th
    0 Files
  • 20
    Mar 20th
    0 Files
  • 21
    Mar 21st
    0 Files
  • 22
    Mar 22nd
    0 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    0 Files
  • 26
    Mar 26th
    0 Files
  • 27
    Mar 27th
    0 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2020 Packet Storm. All rights reserved.

Security Services
Hosting By