# SECURITY BULLETIN: Sentinel Incorrectly Parses Negation In Certain Policy Expressions **URL:** \ **Category:** Sentinel\ **Created:** [February 13, 2020, 11:25pm UTC](https://discuss.hashicorp.com/t/security-bulletin-sentinel-incorrectly-parses-negation-in-certain-policy-expressions/5955 "2020-02-13T23:25:41Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![vancluever](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/vancluever/32/1346_2.png) [@vancluever](https://discuss.hashicorp.com/u/vancluever)\ **Post date:** [February 13, 2020, 11:25pm UTC](https://discuss.hashicorp.com/t/security-bulletin-sentinel-incorrectly-parses-negation-in-certain-policy-expressions/5955/1 "2020-02-13T23:25:41Z")
_The following is a security advisory for the Sentinel runtime regarding a parser issue that was fixed in the runtime in late June 2019. The advisory has been released now that all Sentinel integrations have updated to a version of the runtime that has addressed this issue. See below for more details._ ## Sentinel Incorrectly Parses Negation In Certain Policy Expressions Vulnerability ID: CVE-2019-19879 Release Date: February 12, 2020 Affected Products/Versions: Previous versions of Sentinel; fixed in 0.10.2. A vulnerability was identified in Sentinel such that, within specifically-constructed policy expressions, negations may not be correctly parsed. This vulnerability affects all previous releases of Sentinel, and was fixed in the 0.10.2 release. Policies containing expressions utilizing this incorrectly-parsed negation may not have the intended effect, which may have security implications for systems relying on those policies. The impact of successful exploitation of this vulnerability would be very environment-dependent. This document outlines details about this vulnerability and describes steps for remediation, as well as options to consider if an upgrade is not possible. ### Background HashiCorp [Sentinel](https://www.hashicorp.com/sentinel/) is an embeddable policy-as-code framework to enable fine-grained, logic-based policy decisions that can be extended to source external information to make decisions. Policies written in the Sentinel [policy language](https://docs.hashicorp.com/sentinel/language/) are parsed and evaluated within the Sentinel runtime, with decisions enforced by the broader system system into which Sentinel is embedded. ### Vulnerability Details The Sentinel policy language allows certain operators to be negated with the `not` token to assist with human readability. Specifically, `not` can be used in forms such as `not contains`, `not in`, and `not matches`, where in this case they are the equivalent of a negation of the actual unary result (e.g. `"foo" not in "foobar"` is the same as `!("foo" in "foobar")`). As can be seen in [Operator Precedence](https://docs.hashicorp.com/sentinel/language/spec/#operator-precedence) in the Sentinel specification, relational operators such as `contains`, `in`, and `matches` sit in the middle of the precedence order, with arithmetic operators and `else` having higher precedence. `else` is usually used in these kinds of policies to escape undefined, a handleable error scenario in Sentinel, like so: ```auto foo else "foo" not in "foobar" ``` In these scenarios, an issue in the state machine was causing the not predicate to be ignored, having the opposite effect and effectively making this expression the same as: ```auto foo else "foo" in "foobar" ``` This also applied to scenarios where arithmetic operators were used for operations such as concatenation, as in the following example: ```auto "foo" + "bar" not in "foobar" ``` This issue affects specifically-constructed policy expressions containing operators where a `not` predicate can be used, which applies to the relational/set operators `contains`, `in`, and `matches`. ### Remediation Customers should move to recent versions of HashiCorp enterprise products, as they have incorporated this fix. Specifically, the Sentinel version in which this issue was addressed was included in Vault Enterprise 1.2.0, Terraform Enterprise v201907-1, Consul Enterprise 1.7.0 and Nomad Enterprise 0.10.1. If using Sentinel through an integration, customers may check that particular product to verify it contains the runtime 0.10.2 or higher: - To confirm the runtime version in a Sentinel integration, use the `runtime` import (introduced in Sentinel 0.6.0) and debug messaging. Forcing a policy failure is usually enough to print debug messages: ```auto import "runtime" print(runtime.version) main = false ``` - To confirm the runtime version in the Sentinel Simulator, run the `sentinel version` CLI command. If upgrade is not possible, customers may consider evaluating their Sentinel policies for the incorrectly-parsed policy construction, and rewriting with a variable as an intermediary: ```auto foo = foo else "foo" main = foo not in "foobar" ``` Policy authors should confirm that the policy does not change by using `sentinel fmt`, with a Sentinel CLI version older than 0.10.2, as available at [https://releases.hashicorp.com/sentinel/](https://releases.hashicorp.com/sentinel/). Additionally, authors should ensure that they apply appropriate testing to all of their policies to assert they are behaving as expected. Please contact [support@hashicorp.com](mailto:support@hashicorp.com) with any questions or [security@hashicorp.com](mailto:security@hashicorp.com) to report any security vulnerability or issue. ---
**Author:** ![vancluever](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/vancluever/32/1346_2.png) [@vancluever](https://discuss.hashicorp.com/u/vancluever)\ **Post date:** [February 13, 2020, 11:25pm UTC](https://discuss.hashicorp.com/t/security-bulletin-sentinel-incorrectly-parses-negation-in-certain-policy-expressions/5955/2 "2020-02-13T23:25:57Z")
Closed on February 13, 2020, 11:25pm UTC