Impact
When a user asks SOPS to decrypt a file, SOPS tries first offline and then online identities specified in the encrypted file's metadata to decrypt the file's secret key. If the metadata contain a HashiCorp Vault key (hc_vault), and SOPS can find a token, it will contact the vault_address provided in the metadata with the user's token in the X-Vault-Token HTTP header. SOPS will look for a token in ~/.vault-token, and HashiCorp Vault's client will look for a token in the VAULT_TOKEN environment variable if SOPS does not provide one.
So if a user has a Vault token set up in ~/.vault-token or VAULT_TOKEN, and decrypts an attacker-provided SOPS-encrypted file that contains a malicious vault_address value, SOPS will exfiltrate the token by sending it to the server provided in vault_address.
Patches and mitigations
In SOPS < 3.13.0, the best mitigation is to have a file ~/.vault-token that contains an invalid token. This unfortunately prevents SOPS from decrypting any file that requires a Vault / OpenBao server to decrypt it.
SOPS 3.13.0 introduces a new environment variable SOPS_HC_VAULT_ALLOWLIST that configures which Vault / OpenBao servers SOPS is allowed to contact:
- When set to
all, there is no restriction. This is the same behavior as for SOPS < 3.13.0, and currently the default value.
- When set to
none, SOPS will never contact a Vault / OpenBao server to decrypt a file.
- When set to a comma-separated URL of host prefixes, like
https://vault.example.com:1234, https://secrets.example.org/, SOPS will only contact Vault / OpenBao servers specified in vault_address that start with one of the listed prefixes. Note that the prefix https://vault.example.com:123 does not match https://vault.example.com:1234, and https://vault.example.co does not match https://vault.example.com.
We strongly recommend to upgrade to SOPS 3.13.0 or newer, and to set SOPS_HC_VAULT_ALLOWLIST as restrictively as possible.
Future versions of SOPS will eventually change the default to none, without waiting for a new major release 4.0.0. So if you do use Vault / OpenBao to encrypt and decrypt files, make sure to set SOPS_HC_VAULT_ALLOWLIST explicitly.
References
- https://getsops.io/docs/#restricting-hc-vault-servers-that-sops-can-talk-to
- #2164
|
func userVaultToken() (string, error) { |
|
homePath, err := homedir.Dir() |
|
if err != nil { |
|
return "", fmt.Errorf("error getting user's home directory: %w", err) |
|
} |
|
tokenPath := filepath.Join(homePath, defaultTokenFile) |
|
|
|
f, err := os.Open(tokenPath) |
|
if err != nil { |
|
if errors.Is(err, os.ErrNotExist) { |
|
return "", nil |
|
} |
|
return "", err |
|
} |
|
defer f.Close() |
|
|
|
buf := bytes.NewBuffer(nil) |
|
if _, err := io.Copy(buf, f); err != nil { |
|
return "", err |
|
} |
|
return strings.TrimSpace(buf.String()), nil |
|
} |
- https://github.com/hashicorp/vault/blob/95a58c3584b44c02b31ad18b9115a26b721bd3fa/api/client.go#L665
For more information
If you have any questions or comments about this advisory:
Impact
When a user asks SOPS to decrypt a file, SOPS tries first offline and then online identities specified in the encrypted file's metadata to decrypt the file's secret key. If the metadata contain a HashiCorp Vault key (
hc_vault), and SOPS can find a token, it will contact thevault_addressprovided in the metadata with the user's token in theX-Vault-TokenHTTP header. SOPS will look for a token in~/.vault-token, and HashiCorp Vault's client will look for a token in theVAULT_TOKENenvironment variable if SOPS does not provide one.So if a user has a Vault token set up in
~/.vault-tokenorVAULT_TOKEN, and decrypts an attacker-provided SOPS-encrypted file that contains a maliciousvault_addressvalue, SOPS will exfiltrate the token by sending it to the server provided invault_address.Patches and mitigations
In SOPS < 3.13.0, the best mitigation is to have a file
~/.vault-tokenthat contains an invalid token. This unfortunately prevents SOPS from decrypting any file that requires a Vault / OpenBao server to decrypt it.SOPS 3.13.0 introduces a new environment variable
SOPS_HC_VAULT_ALLOWLISTthat configures which Vault / OpenBao servers SOPS is allowed to contact:all, there is no restriction. This is the same behavior as for SOPS < 3.13.0, and currently the default value.none, SOPS will never contact a Vault / OpenBao server to decrypt a file.https://vault.example.com:1234, https://secrets.example.org/, SOPS will only contact Vault / OpenBao servers specified invault_addressthat start with one of the listed prefixes. Note that the prefixhttps://vault.example.com:123does not matchhttps://vault.example.com:1234, andhttps://vault.example.codoes not matchhttps://vault.example.com.We strongly recommend to upgrade to SOPS 3.13.0 or newer, and to set
SOPS_HC_VAULT_ALLOWLISTas restrictively as possible.Future versions of SOPS will eventually change the default to
none, without waiting for a new major release 4.0.0. So if you do use Vault / OpenBao to encrypt and decrypt files, make sure to setSOPS_HC_VAULT_ALLOWLISTexplicitly.References
sops/hcvault/keysource.go
Lines 437 to 458 in dbb597b
For more information
If you have any questions or comments about this advisory: