SECURITY BULLETIN: Sentinel Incorrectly Parses Negation In Certain Policy Expressions

Sentinel
1

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 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 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 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:

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:

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:

"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:
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:

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/.

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 with any questions or security@hashicorp.com to report any security vulnerability or issue.

1 Like