Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: A copy-paste typo in the GLES2 passthrough decoder leaves the name_offset field of the TransformFeedbackVaryingInfo struct uninitialized. This struct is subsequently copied to a command buffer bucket returned to the renderer. On Android official builds where stack variables are not auto-initialized, this potentially leaks 4 bytes of GPU process stack memory per varying, providing an ASLR bypass primitive.

Affected files:

• gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doers.cc

Estimated timestamp from git blame: 2017-03-24

Description

In the GPU process’s passthrough command buffer decoder, there is a copy-paste typo when populating transform feedback varying information.

In gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doers.cc, the function GLES2DecoderPassthroughImpl::DoGetTransformFeedbackVaryingsCHROMIUM iterates through a program’s varyings and populates a stack-allocated TransformFeedbackVaryingInfo struct:

    TransformFeedbackVaryingInfo varying_info;
    varying_info.size = size;
    varying_info.type = type;

    DCHECK(length + 1 <= max_transform_feedback_varying_length);
    varying_info.name_length = data->size();  // <-- TYPO HERE
    varying_info.name_length = length + 1;

The line varying_info.name_length = data->size(); was clearly intended to be varying_info.name_offset = data->size();. Because it incorrectly assigns to name_length (which is immediately overwritten on the next line), the 4-byte name_offset field of the 16-byte struct is never initialized.

The uninitialized struct is then copied into the response vector data via InsertValueIntoBuffer, which uses memcpy. Finally, the vector is placed into a command buffer bucket and returned to the renderer.

On Android official builds, the compiler flag init_stack_vars is set to false (in build/config/compiler/BUILD.gn) to optimize binary size and performance. As a result, the uninitialized name_offset field will contain 4 bytes of leftover data from the GPU process’s stack. Leaking this data to a compromised renderer provides a reliable ASLR bypass primitive against the GPU process.

Potential Attacker Steps

Note: These are suggested steps based on static analysis, as our tooling agent does not yet have the ability to run code to verify a full exploit chain.

1. Compromise the Renderer: The attacker first gains arbitrary code execution in the sandboxed renderer process.
2. Context Creation: The attacker establishes a WebGL2 or OpenGL ES 3.0 context.
3. Program Setup: The attacker compiles and links a shader program containing one or more transform feedback varyings.
4. Command Execution: The attacker crafts and sends the GetTransformFeedbackVaryingsCHROMIUM command via the GPU command buffer, providing the valid program ID and a target bucket ID.
5. Data Retrieval: The attacker issues GetBucketStart / GetBucketData commands to read the populated bucket from shared memory.
6. Information Leak: The attacker parses the returned binary structure and extracts the 4 bytes at the name_offset position for each varying. These 4 bytes contain leaked stack memory from the GPU process, which can be used to defeat ASLR.

Proposed Fix

Correct the typo by assigning the offset to the correct field. Additionally, explicitly zero-initialize the struct at declaration to protect against any future changes to the struct definition.

    TransformFeedbackVaryingInfo varying_info = {}; // Explicitly zero-initialize
    varying_info.size = size;
    varying_info.type = type;

    DCHECK(length + 1 <= max_transform_feedback_varying_length);
    varying_info.name_offset = data->size();        // Fix typo
    varying_info.name_length = length + 1;

Evaluated with Chrome root at commit: ff3d2b74fa39431785bd60e51463b08fcc71ee33

Results from 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.