Flapjack, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A deterministic identifier collision in ANGLE’s HLSL translator allows local variables to shadow global variables in the generated HLSL code. This shadowing causes AST-based array bounds checks to be applied to the wrong variable, potentially leading to out-of-bounds reads and writes on the GPU stack.

Affected files:

• third_party/angle/src/compiler/translator/hlsl/UtilsHLSL.cpp

Estimated timestamp from git blame: 2019-02-04

Background

When ANGLE translates GLSL to HLSL for the Direct3D backend, it decorates identifiers to avoid name collisions. This logic is implemented in DecorateVariableIfNeeded within third_party/angle/src/compiler/translator/hlsl/UtilsHLSL.cpp.

Global variables are decorated by prepending an underscore _. For example, a global variable named a3005 becomes _a3005.

Local variables (which receive the EvqTemporary qualifier) are decorated by prepending _ and appending the variable’s internal sequential uniqueId. For example, a local variable named a that is assigned a uniqueId of 3005 also becomes _a3005.

Vulnerability Details

Because TSymbolTable resets its mUniqueIdCounter to kFirstUserDefinedSymbolId (3000) at the start of every shader compilation, unique IDs are assigned deterministically. An attacker can control a local variable’s ID by declaring a specific number of dummy variables prior to it.

This predictable assignment allows a local variable to intentionally collide with the decorated name of a global variable. When the HLSL is generated, standard scoping rules apply, and the local declaration within the function shadows the global declaration.

This shadowing bypasses ANGLE’s array bounds checking pass, ClampIndirectIndices. The pass inserts a clamp() operation based on the size of the array in the Abstract Syntax Tree (AST). If the AST correctly points to a large global array, a large clamp bound is generated. However, the underlying HLSL compiler will execute this clamped access against the shadowed, smaller local array, resulting in out-of-bounds memory access.

Potential Attacker Steps

An attacker could potentially trigger this by supplying the following WebGL shader:

1. Declare a large global array: float a3005[100];.
2. Declare dummy variables to increment the internal symbol ID counter to exactly 3004.
3. Inside a function, declare a small local array: float a[1];. This variable receives uniqueId 3005.
4. Access the global array using an attacker-controlled index: a3005[index];.

During compilation:

• ClampIndirectIndices analyzes the AST, sees the access to the global a3005 of size 100, and emits: clamp(index, 0, 99).
• OutputHLSL generates the global variable: static float _a3005[100];.
• OutputHLSL generates the local variable, creating a name collision: float _a3005[1];.
• OutputHLSL generates the array access: _a3005[clamp(index, 0, 99)].

When the HLSL executes, _a3005 resolves to the local array of size 1. An attacker supplying an index of 50 will read/write memory far past the end of the local array on the GPU’s stack or registers.

(Note: These are potential steps based on code analysis; our tooling agent does not yet have the ability to run code to confirm a live exploit.)

Impact

Out-of-bounds reads and writes on the GPU can lead to arbitrary code execution within the GPU process. On platforms where HLSL is used (primarily Windows), this constitutes a sandbox escape from the highly restricted WebGL renderer process into the GPU process.

Suggested Fix

The decoration scheme for temporary variables should use a separator that cannot be part of a user-defined GLSL identifier. Since WebGL shaders are restricted from using double underscores __ or starting identifiers with certain characters, using a safer decoration pattern would prevent these collisions.

For example, in third_party/angle/src/compiler/translator/hlsl/UtilsHLSL.cpp:

return Decorate(variable.name()) + "__" + str(variable.uniqueId().get());

Evaluated with Chrome root at commit: 2155cb00003ec35716a76ed3246eae995f87b7ff

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.