Add depth validation for ASTs loaded through ParsedExprToAst / Checke...

[wilyan09007]

Summary

cel-go enforces a recursion/expression-depth limit while parsing CEL source, but ASTs ingested directly — through ParsedExprToAst / CheckedExprToAst — bypass that guard. A deeply nested loaded AST then flows into the recursive checker (Env.Check) and planner (Env.Program / PlanProgram), which can exhaust the Go stack and abort the process with fatal error: stack overflow instead of returning a recoverable error. Embedders that load stored or serialized CEL ASTs as policy objects are the most exposed.

This validates expression nesting depth before those recursive phases:

• Adds ast.ExceedsMaxDepth(expr, maxDepth) in common/ast — a bounded traversal that never recurses past maxDepth+1 levels, so it stays safe on the same adversarially deep inputs it guards against. The default ast.MaxNestingDepth = 250 mirrors the parser's default maxRecursionDepth, keeping loaded ASTs consistent with parsed ones.
• Env.Check and Env.PlanProgram now run that check up front and return an ordinary error/issue — input exceeds maximum expression nesting depth: 250 — rather than recursing into a stack overflow.
• Adds a regression test that loads a synthetic over-deep AST and asserts Check and Program return an error (not a crash), while normal expressions remain unaffected.

Closes #1333

[TristonianJones]

It's preferred to create functional options with sensible defaults for user-configurable behavior. CEL doesn't currently validate the AST size on load since the parser should be the only entry point for a user-authored AST. Defense in depth is great, but could you please hoist this out of a publicly mutable variable and add it to the cel.NewEnv as a functional option that gets checked during Program calls?

[TristonianJones]

Prefer instead to use a visitor that observes the expression depth to the navigable.go file.

Existing methods:

cel-go/common/ast/navigable.go

Lines 174 to 183 in f456a6e

	// PostOrderVisit walks the expression graph and calls the visitor in post-order (bottom-up).
	func PostOrderVisit(expr Expr, visitor Visitor) {
	visit(expr, visitor, postOrder, 0, 0)
	}
	// PreOrderVisit walks the expression graph and calls the visitor in pre-order (top-down).
	func PreOrderVisit(expr Expr, visitor Visitor) {
	visit(expr, visitor, preOrder, 0, 0)
	}

Proposed impl:

// ExceedsDepth determines whether the AST contains expressions nested beyond a specified maxDepth.
func ExceedsDepth(a *AST, depth int) bool {
  exceedsDepth := false
  visitor := NewExprVisitor(func(e Expr) {
      nav := e.(NavigableExpr)
      if nav.Depth() >= depth {
        exceedsDepth = true
      }
  })
  root := NavigateAST(a)
  PostOrderVisit(root, visitor)
  return exceedsDepth
}

[TristonianJones]

Maybe if the maxDepth is 0 just skip the check. The other alternative is to shift this check to the io.go file instead which converts from the proto representation to the AST. In fact, let's maybe do that instead since a hand-rolled golang AST isn't possible without full control of the code.

[TristonianJones]

Let's instead add the depth check in the ParsedExprToAst and CheckedExprToAst since the program construction path is the hot path and the defense in depth check should be something users can disable if it doesn't apply since it's added compute without added security in a number of cases.

[TristonianJones]

/gcbrun