CVE-2019-12291: Unauthorized Key/Value Deletion

[pearkes]

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.

Summary

You should take action if you use the key_prefix or key ACL rules and Consul 1.4.0 - 1.5.0 to grant partial write access to the K/V store in Consul.

Steps to remediate:

1. Review usage to determine presence of key_prefix or key ACL rules and determine if this behavior of being able to delete more data from the KV then should be allowed, is being relied upon for normal operations. This is unlikely, but writing a new ACL rule may cause negative impact if so which would manifest itself as permission denied responses for recursive KV deletes that previously worked.
2. Add an additional rule that disallows access to all prefixes other than the ones you explicitly grant access to. This should be added to all policies where partial write access is granted.

key_prefix "" { policy = "deny" }

Alternatively, upgrading to 1.5.1 or 1.4.5 will resolve the issue.

Background

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 foo/ if the tree has keys such as foo/bar/baz and foo/bar/bat.

First, Consul ensures the token has generic write access over the whole prefix. Given a rule as below:

key_prefix "foo/" { policy = "write" } 

This key prefix rule would satisfy access for a key such as foo/bar/baz unless there is a more specific/longer prefix rule, that does not grant write access such as:

key_prefix "foo/bar/" { policy = "read" }

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 deny) Consul instead continues on to the next step only if there were no applicable rules found.

This bug was introduced in version 1.4.0 of Consul and is fixed in Consul 1.4.5 and 1.5.1.

Remediation

Users can add an additional rule to ACL policies to immediately remediate this issue:

key_prefix "" { policy = "deny" }

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.

[pearkes]

Fixed by 36ebca1.