Skip to content

Privilege escalation in Strongbox

Moderate severity GitHub Reviewed Published Feb 15, 2023 in schibsted/strongbox • Updated Apr 10, 2023

Package

maven com.schibsted.security:strongbox-sdk (Maven)

Affected versions

< 0.5.0

Patched versions

0.5.0

Description

Impact

An attacker with read-only access to a Strongbox secret could craft a valid encrypted secret (same id/version). It also makes the audit logs from KMS less useful. The issue is caused by a bug in the underlying AWS Encryption SDK.

By default, the encrypted secrets are stored in DynamoDB and an attacker with read-only access would not be able to write the encrypted secret to DynamoDB. So in practice the impact should be limited for most users.

Strongbox supports storing data in files as an alternative to DynamoDB. If the attacker had write access to where the files are stored they could make the attack work end-to-end. Similarly, any custom storage backend could also be affected.

In order to be backwards compatible Strongbox will not make use of key commitments (another improvement to the AWS Encryption SDK). Strongbox enforces that only one KMS key can be used, and it must match the expected one. This means that an attacker needs write access to both KMS and DynamoDB (or other storage backend) to stage an attack, which is not a scenario Strongbox is designed to protect against.

Patches

Fixed in version 0.5.0.

Workarounds

None

References

References

@stiankri stiankri published to schibsted/strongbox Feb 15, 2023
Published to the GitHub Advisory Database Feb 16, 2023
Reviewed Feb 16, 2023
Last updated Apr 10, 2023

Severity

Moderate

Weaknesses

CVE ID

No known CVE

GHSA ID

GHSA-mhgm-52vg-pvvc

Source code

Credits

Checking history
See something to contribute? Suggest improvements for this vulnerability.