A security vulnerability has been identified in GPFS V4.1 where the private key of TLS client certificates used by GPFS nodes may be contained in a gpfs.snap file (CVE-2015-1890).
DESCRIPTION: IBM General Parallel File System could allow someone who has access to a snap file generated by the gpfs.snap tool (/usr/lpp/mmfs/bin/gpfs.snap) to read the private keys of certificates used by GPFS for daemon communications via the TLS protocol.
CVSS Base Score: 3.5
CVSS Temporal Score: See http://xforce.iss.net/xforce/xfdb/101382 for the current score
CVSS Environmental Score*: Undefined
CVSS Vector: (AV:N/AC:M/Au:S/C:P/I:N/A:N)
GPFS includes a gpfs.snap service tool shipped as /usr/lpp/mmfs/bin/gpfs.snap. The tool is generally used to collect diagnostics data that can be sent to IBM Service in case of problems with GPFS.
A security vulnerability has been uncovered where a snap file created by the gpfs.snap tool may collect the private keys from the nodes.
The files collected may contain certificates, public keys and private keys that the node will use for i) communication between GPFS daemons using the TLS protocol and ii) communication between GPFS daemons and remote key servers using the TLS protocol. With access to those files, an attacker may impersonate a GPFS node in the cluster or decrypt messages which have been sent between legitimate GPFS daemons. An attacker may also retrieve master encryption keys used for file encryption.
Note that, upon execution of gpfs.snap, the resulting 'tar' archive file containing cluster diagnostics is owned by root and is not readable by nonroot users. If any administrative action is taken to make the file readable by other users then those users will be able to open the 'tar' file and then retrieve the private key file which is stored inside the archive.
Affected Products and Versions
GPFS V22.214.171.124 thru GPFS V126.96.36.199
Install GPFS 188.8.131.52. Once that level is applied, future snaps produced by the gpfs.snap tool will no longer collect private keys.
If a customer is concerned that the private keys used for the communication between GPFS daemons using the TLS protocol may have been compromised by this vulnerability, then the customer should regenerate public/private key pairs. For information on how to do so, consult the Changing security keys section in Chapter 1, Accessing GPFS file systems from other GPFS Clusters of the GPFS Advanced Administration Guide, which you can find by clicking on the link to GPFS product documentation (EPUB/PDF) at http://www-01.ibm.com/support/knowledgecenter/SSFKCN/gpfs_welcome.html?lang=en.
If a customer is concerned that the private keys used for the communication between GPFS daemons and remote key servers using the TLS protocol may have been compromised by this vulnerability, then the customer should:
- Identify all RKM backend stanzas in /var/mmfs/etc/RKM.conf referencing the compromised ISKLM certificates; and
- For each backend stanza identified, execute the steps below:
- a) Generate a new client key pair and certificate as described in step 5 Configure the RKM backend on GPFS in the section Establishing an encryption-enabled environment in Chapter 15 - Encryption of the GPFS Advanced Administration Guide.
- b) Generate a new RKM stanza as described in step 5 of Configure the RKM backend on GPFS . The name of the new backend stanza must be different from the old one. Let us assume that the old name was "RKM_OLD" and that the new one is "RKM_NEW";
- c) Append the new RKM stanza to /var/mmfs/etc/RKM.conf.
d) Edit the encryption policies that are currently active (they can be retrieved by running the mmlspolicy device -L command) replacing every occurrence of the RkmId "RKM_OLD" with "RKM_NEW" in the Keyname strings referenced by your "ENCRYPTION IS" rules.
- e) Install the new policy using the mmchpolicy command.
- f) Import the new client certificate into ISKLM as described in steps 6.c through 6.h of step 5 Configure the RKM backend on GPFS in the section Establishing an encryption-enabled environment in Chapter 15 - Encryption of the GPFS Advanced Administration Guide.
- g) Delete the compromised certificate: from the main page of the ISKLM web GUI, select the appropriate GPFS tenant device group, click Go to... and select Manage keys and devices from the dropdown menu. On the left part of the next screen you'll see a list of certificates that have access to the keys in the device group. Identify the compromised certificates, right click on them, select Delete and confirm the deletion at the prompt.
If a customer is concerned that the Master Encryption Keys (MEKs) used for file encryption may have been compromised by this vulnerability, then the customer should:
- Generate new MEKs.
- Update the encryption policy rules with the new MEKs.
- Follow instructions similar to those described in the Secure deletion section of Chapter 15 - Encryption in the GPFS Advanced Administration Guide to change the MEKs of the existing files; and
- Remove the original MEKs from the ISKLM key server.
Note that deleting master encryption keys may result in irreparable data loss. If you are uncertain about the mitigation steps, contact the IBM support team.
Workarounds and Mitigations
Get Notified about Future Security Bulletins
changed the expiration date
*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.
According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY.
25 June 2021