Bulletin ID: HCSEC-2021-09
Affected Products / Versions: Vault and Vault Enterprise 1.5.1 and newer; fixed in 1.5.8, 1.6.4, and 1.7.1.
Publication Date: April 21, 2021
Summary
Vault and Vault Enterprise (“Vault”) PKI Secrets Engine tidy functionality may cause Vault to exclude revoked-but-unexpired certificates from the Vault CRL. This vulnerability, CVE-2021-29653, was fixed in Vault and Vault Enterprise 1.5.8, 1.6.4, and 1.7.1.
Background
The Vault PKI Secrets Engine generates dynamic X.509 certificates, supported by Vault’s built-in authentication and authorization mechanisms. Vault provides API endpoints for certification generation and certificate revocation, among other PKI actions. Vault also exposes a certificate revocation list (CRL) that can be used to enforce certificate revocation.
The PKI Secrets Engine’s tidy endpoint allows tidying up the storage backend and/or CRL by removing certificates that have expired and are past a certain buffer period beyond their expiration time. The tidy_revoked_certs parameter, which defaults to false, can be set to true to expire all revoked and expired certificates, removing them both from the CRL and from storage.
Details
It was discovered that a change to the tidy_revoked_certs logic, released in Vault 1.5.1, had an unintended effect of removing revoked-but-unexpired certificates from Vault’s CRL. Environments that utilize this feature may have such certificates excluded from their CRL after a tidy operation and subsequently treated as valid since they are no longer in the CRL and not yet past their NotAfter value.
The tidy_revoked_certificates logic for Vault 1.5.1 permanently removed the revoked certificates from Vault storage and, even when the update is applied, a correct CRL cannot be regenerated.
Exposure to this issue requires several conditions to be met:
- Use the PKI Secrets Engine provided by Vault 1.5.1 or newer.
- Use the PKI engine’s certificate revocation mechanism.
- Use and enforce the PKI engine’s certificate revocation list.
- Use the PKI engine’s tidy mechanism, with tidy_revoked_certs parameter set to non-default true.
Condition 1 may be investigated by obtaining the current Vault version through the web UI or the /sys/health endpoint. Conditions 2, 3, and 4 may be investigated by reviewing Vault audit or Vault supporting infrastructure (eg. load balancer) logs for usage of the certificate revocation, CRL, and tidy API endpoints (/pki/revoke, /pki/crl, and /pki/tidy).
Even with all conditions met, exposure will be environment-dependent and will vary depending on PKI design, PKI certificate use case, and certificate TTL.
Remediation
Customers should review their Vault environment for the conditions noted above, evaluate the risk associated with this issue, and consider upgrading to Vault Enterprise 1.5.8 / 1.6.4 / 1.7.1 or newer. Please refer to Upgrading Vault for general guidance and version-specific upgrade notes.
Customers for whom the four conditions noted above are true should consider exposure in the context of their environment and PKI design. For example, if all conditions above have been met in an environment where long-lived certificates have been issued and subsequently revoked, and the exclusion of these certificates from the CRL presents unacceptable risk, then it may be necessary to rotate root and/or intermediate CAs to force invalidation of those certificates.
More generally, customers using the PKI secrets engine should consider the lifetime of certificates being issued. By keeping TTLs relatively short, revocations are less likely to be needed, keeping CRLs short and helping the secrets engine scale to large workloads. The Vault documentation contains guidance on this topic.
Acknowledgement
This issue was identified by an external party who reported it to HashiCorp.
We deeply appreciate any effort to discover and disclose security vulnerabilities responsibly. For information about security at HashiCorp and the reporting of security vulnerabilities, please see https://hashicorp.com/security.