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 Chrome Security team.

Overview: The validating command decoder fails to verify if native drivers successfully clear ETC1/ATC compressed textures. Because the GL specification forbids glCompressedTexSubImage2D for these formats, native drivers reject the clear operation, leaving VRAM uninitialized. A malicious WebGL page could potentially sample this uninitialized memory, leading to cross-origin or cross-process information disclosure.

Affected files:

• gpu/command_buffer/service/gles2_cmd_decoder.cc
• gpu/command_buffer/service/texture_manager.cc
• gpu/command_buffer/service/feature_info.cc

Estimated timestamp from git blame: 2024-04-10

Description

There is a potential uninitialized memory disclosure vulnerability in the GLES2 validating command decoder (predominantly used on Android or when ANGLE is not active). The issue stems from a failure to check for OpenGL errors during the lazy-clearing of specific compressed texture formats, namely GL_ETC1_RGB8_OES and GL_ATC_*_AMD.

When a WebGL application allocates an immutable texture using texStorage2D, the command buffer allocates VRAM but correctly marks it as uninitialized. Before this texture can be sampled in a draw call, the decoder must zero-initialize it to prevent leaking sensitive cross-origin or cross-process VRAM.

The clearing logic in GLES2DecoderImpl::ClearCompressedTextureLevel (gpu/command_buffer/service/gles2_cmd_decoder.cc) attempts to zero-fill the texture by calling the native driver’s glCompressedTexSubImage2D with a buffer of zeros. However, the Khronos specifications for OES_compressed_ETC1_RGB8_texture and AMD_compressed_ATC_texture explicitly state that glCompressedTexSubImage2D is not supported for these formats.

Consequently, compliant native drivers reject the sub-image update with a GL_INVALID_OPERATION error and leave the VRAM unmodified. Because ClearCompressedTextureLevel does not check for GL errors (e.g., via glGetError()) after making the call, it unconditionally returns true. The TextureManager then erroneously marks the texture level as fully cleared, allowing the renderer to sample uninitialized VRAM in subsequent draw calls.

Potential Exploitation Steps

Note: These steps are suggested based on code analysis; our tooling agent does not run code, so a working proof-of-concept has not been executed.

An attacker could potentially exploit this via the following sequence:

1. Request a WebGL 2.0 context to ensure texStorage2D retains the compressed internal format (avoiding fallback behaviors in WebGL 1.0).
2. Allocate an immutable texture using gl.texStorage2D with the COMPRESSED_RGB8_ETC1_WEBGL format.
3. Create a standard RGBA8 Framebuffer Object (FBO) and attach it as the rendering destination.
4. Create a shader program with a fragment shader that samples from the ETC1 texture and writes the output to the gl_FragColor.
5. Bind the uninitialized ETC1 texture to the sampler and issue a draw call (e.g., gl.drawArrays).
6. The command buffer attempts to lazy-clear the ETC1 texture using glCompressedTexSubImage2D, which fails silently on the native driver.
7. The draw call proceeds, sampling uninitialized VRAM (which may contain decrypted media frames, pixels from other tabs, or OS UI elements) into the RGBA8 FBO.
8. The attacker calls gl.readPixels on the FBO to exfiltrate the leaked memory.

Suggested Fix

There are two primary ways to address this issue:

1. Check for GL Errors: Modify GLES2DecoderImpl::ClearCompressedTextureLevel to verify the success of the clear operation using LOCAL_PEEK_GL_ERROR after calling api()->glCompressedTexSubImage2DFn. If an error occurred, the function should return false so the texture remains marked as uncleared.
2. Prevent Allocation: If a platform’s native driver cannot clear ETC1/ATC textures because it strictly adheres to the extension specification prohibiting sub-image updates, Chromium should prevent these formats from being allocated via TexStorage2D (or explicitly implement a software fallback workaround for initialization).

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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.