HCSEC-2021-20 - Vault’s Integrated Storage Backend Database File May Have Excessively Broad Permissions

Bulletin ID: HCSEC-2021-20
Affected Products / Versions: Vault and Vault Enterprise 1.4.0 up to 1.7.3; fixed in 1.8.0.
Publication Date: August 12, 2021

Summary
When initializing Vault’s Integrated Storage backend, excessively broad filesystem permissions may be set for the underlying Bolt database used by Vault’s Raft implementation. This vulnerability, CVE-2021-38553, was fixed in Vault 1.8.0.

Background
Vault’s Integrated Storage was introduced in Vault 1.4.0, providing a built-in highly available storage backend. As documented, the Integrated Storage backend uses the Raft consensus protocol, which uses BoltDB as an underlying datastore.

Details
During initialization of the Integrated Storage backend, Vault creates a database file on disk with potentially excessive filesystem permissions, though these vary depending on the operating system’s umask values. This vault.db file is written to the location configured by the path parameter in Vault’s Raft configuration.

Most Vault environments are unlikely to have significant exposure as a result of this issue:

  • Only Vault clusters utilizing Integrated Storage are affected.

  • The default system umask on each Vault node will likely cause a less-broad permission to be applied.

  • In the Vault security model, storage backends are considered untrusted by design. Barrier encryption is applied before data is written to Vault storage backends including Integrated Storage, guarding against unauthorized access or tampering of data. However, the database file could be deleted, potentially resulting in denial of service.

  • Vault’s production hardening guide recommends a single tenancy model, which reduces the likelihood of another process or user manipulating the host’s filesystem.

Remediation
Customers using Vault’s Integrated Storage should evaluate the risk associated with this issue in conjunction with the mitigating factors noted above, and consider reviewing and possibly updating filesystem permissions for the vault.db file across their Vault nodes.

New deployments of Vault or Vault Enterprise 1.8.0 or newer will create the Integrated Storage database with more restrictive filesystem permissions by default.

Acknowledgement
This issue was identified by the Vault engineering team.

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.

Update Regarding Risk Scoring

The CVSS score originally published to the NIST NVD for this issue was 9.8 (Critical), with a vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

In contrast, HashiCorp’s internal CVSS scoring was 4.4 (Medium), with a vector string CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H.

Points for consideration regarding this score:

  • To exploit this vulnerability, the attacker requires code execution on the host running the Vault process. For this reason, Attack Vector should be Local, and Privileges Required should be High.
  • Storage Backends in Vault are considered untrusted by design: Vault’s Barrier Encryption uses authenticated encryption for any data persisted to storage backends, including the Bolt database in question. As such, impact to Confidentiality and Integrity should be None (impact to Availability remains High).