Project Fortify, 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 without the security team.

Overview: A potential logic flaw in ANGLE’s resource initialization tracking allows an attacker to bypass mandatory zero-initialization of WebGL stencil buffers. By setting matching partial stencil test and write masks, an attacker can trick ANGLE into treating a partial stencil clear as a full clear, leaving uninitialized GPU memory intact to be extracted.

Affected files:

• third_party/angle/src/libANGLE/Framebuffer.cpp

Estimated timestamp from git blame: 2024-09-10

Description

Chromium enforces the WEBGL_robustness extension for all WebGL contexts, which requires robust-resource-init to ensure newly allocated GPU memory is zero-initialized. This prevents malicious web pages from reading stale VRAM from other cross-origin tabs, system UI, or processes.

A potential vulnerability exists in ANGLE’s initialization tracking within third_party/angle/src/libANGLE/Framebuffer.cpp. When a web page clears a buffer, ANGLE determines if the clear covers the entire buffer (a “full clear”). If it does, ANGLE skips explicit zero-initialization, as the user’s clear will safely overwrite all stale data. This is evaluated in Framebuffer::partialClearNeedsInit.

However, the logic used to determine if a stencil clear is partial is flawed:

// Framebuffer::partialClearNeedsInit
const auto &depthStencil       = glState.getDepthStencilState();
const GLuint differentFwdMasks = depthStencil.stencilMask ^ depthStencil.stencilWritemask;
const GLuint differentBackMasks =
    depthStencil.stencilBackMask ^ depthStencil.stencilBackWritemask;

if (((differentFwdMasks | differentBackMasks) & 0xFF) != 0)
{
    return true; // Is partial clear
}

To detect a partial clear, ANGLE incorrectly XORs the stencil test mask (stencilMask, set by glStencilFunc) with the stencil write mask (stencilWritemask, set by glStencilMask). According to the OpenGL ES specification, clear operations are only affected by the write mask; the test mask is irrelevant.

If an attacker sets both the test mask and the write mask to the same partial value (e.g., 0x0F), the XOR evaluates to 0. partialClearNeedsInit falsely returns false, signaling a full clear. ANGLE marks the buffer as safely initialized and skips the zeroing pass. The clear command is sent to the GPU backend, which respects the write mask (0x0F) and only clears the lower 4 bits of the stencil buffer. The upper 4 bits remain uninitialized, retaining stale GPU memory.

Potential Exploitation Steps

Note: These are suggested steps to trigger the vulnerability based on code analysis; our tooling cannot execute code to verify a live proof-of-concept.

An attacker can recover uninitialized bits from GPU memory using a stencil-test oracle by following these potential steps:

1. Initialize a WebGL 2.0 context and create an FBO with a new STENCIL_INDEX8 renderbuffer.
2. Set identical partial masks for both the stencil test and the write mask:

   gl.stencilFunc(gl.ALWAYS, 0, 0x0F);
   gl.stencilMask(0x0F);
   

3. Clear the stencil buffer:

   gl.clearStencil(0);
   gl.clear(gl.STENCIL_BUFFER_BIT);
   

   (At this point, ANGLE marks the buffer as initialized, but the GPU only cleared the bottom 4 bits.)
4. Restore the write mask to 0xFF and enable stencil testing to read back the stale upper 4 bits:

   gl.stencilMask(0xFF);
   gl.enable(gl.STENCIL_TEST);
   for (let ref = 0; ref < 16; ref++) {
       // Oracle: Only pass if the top 4 uninitialized bits match 'ref'
       gl.stencilFunc(gl.EQUAL, ref << 4, 0xF0);
       // Draw a fullscreen quad with a color unique to 'ref'.
       // Use readPixels() to determine the stale memory contents of each pixel.
   }
   

Suggested Fix

Modify Framebuffer::partialClearNeedsInit to only evaluate the stencilWritemask. A stencil clear should be considered partial if the write mask does not cover all bits of the currently bound stencil buffer format.

For an 8-bit stencil buffer, the check should simply verify that the mask is 0xFF:

if ((depthStencil.stencilWritemask & 0xFF) != 0xFF ||
    (depthStencil.stencilBackWritemask & 0xFF) != 0xFF)
{
    return true;
}

Evaluated with Chrome root at commit: 137d451a126685dd5010e6609db9f6d4a78d8234

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; 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.