Bulletin ID: HCSEC-2022-09
Affected Products / Versions: Vault and Vault Enterprise 1.8.0 through 1.8.8, and 1.9.3; fixed in 1.8.9 and 1.9.4.
Publication Date: March 4, 2022
Summary
Vault and Vault Enterprise (“Vault”) allowed the PKI secrets engine under certain configurations to issue wildcard certificates to authorized users for a specified domain, even if the PKI role policy attribute allow_subdomains is set to false. This vulnerability, CVE-2022-25243, was fixed in Vault Enterprise 1.8.9 and 1.9.4.
Background
Vault’s PKI secrets engine provides several PKI role policy attributes that allow an operator to granularly define policies:
-
allow_bare_domainsspecifies if the policy can issue a certificate for the exact domain inallowed_domains(e.g.,example[.]com). -
allow_glob_domainspermits the use of a glob*characters in patterns specified inallowed_domains. When disabled,*in aallowed_domainentry will be treated as a wildcard character. -
allow_subdomainsrestricts the issuance of wildcard certificates and certificates for subdomains of those listed inallowed_domains. -
allowed_domainsin combination with the above attributes define an allowlist of domains which this role can issue against.
Details
It was reported that Vault’s PKI secrets engine was unexpectedly permitting the issuance of wildcard certificates when allow_subdomains was set to false. The scenario in question required allow_bare_domains be set to true as well as at least one domain without globs (e.g., example[.]com or subdomain[.]example[.]com) be in the allowed_domains field of a PKI issuance role.
One mitigating factor is that the allow_bare_domains attribute is false by default and must be explicitly enabled by an operator.
Remediation
Customers should evaluate the risk associated with this issue and consider upgrading to Vault Enterprise 1.8.9 and 1.9.4, or newer. Please refer to Upgrading Vault for general guidance and version-specific upgrade notes.
Acknowledgement
This issue was independently identified by both the Vault engineering team and an external party who reported it to HashiCorp.
We deeply appreciate any effort to coordinate disclosure of security vulnerabilities. For information about security at HashiCorp and the reporting of security vulnerabilities, please see Security at HashiCorp.