Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
CVE-2019-12291: Unauthorized Key/Value Deletion #5888
While investigating #5819 (thank you @danlsgiga) it was discovered that if a specific ACL rule is used for prefix matching in a policy, keys not matching that specific prefix can be deleted by a token using that policy even with default deny settings configured.
This vulnerability affects versions 1.4.0 - 1.5.0 of Consul, both OSS and Enterprise. Remediation is possible without an upgrade by adding an additional ACL policy, but upgrades are recommended when possible.
You should take action if you use the
Steps to remediate:
Alternatively, upgrading to 1.5.1 or 1.4.5 will resolve the issue.
When a request is made with an ACL token, Consul takes several steps to determine whether a token is granted write access to a whole prefix in the KV. A prefix may be something like
First, Consul ensures the token has generic write access over the whole prefix. Given a rule as below:
This key prefix rule would satisfy access for a key such as
After determining this, the ACL system will check all rules for keys underneath the prefix and ensure nothing would deny write access. If a default deny setting was used, this is when it would be taken into account and the write access denied.
The vulnerability occurs in the first step as described above. When there is no prefix rule found, instead of falling back to the default policy as described in the second step (commonly
This bug was introduced in version 1.4.0 of Consul and is fixed in Consul 1.4.5 and 1.5.1.
Users can add an additional rule to ACL policies to immediately remediate this issue:
However, we recommend starting a rollout of this rule change with a less critical environment such as a staging environment, given clients could potentially be relying on this previously broken behavior. This may be unlikely given a users specific use-case for K/V.
Users can also follow our standard upgrade procedure and upgrade to Consul 1.4.5 and 1.5.1 which will remediate this issue with no change to ACL policies being necessary.
If the policy remediation is used, it is recommended to upgrade as soon as is convenient, and then remove the added deny prefix once the upgrade is successful. However, retaining the deny rule as described above for a prolonged period should not cause issues other than complexity in rule configuration.