Flapjack (go/flapjack), an LLM-powered static analysis tool, has identified the following potential security issue.

Overview: A compromised renderer process can potentially trigger an out-of-bounds read in the GPU process by supplying a malicious JPEG to the hardware decoder. The JPEG parser fails to validate the quantization table selector, passing an arbitrary index to the VA-API driver. This can leak GPU memory contents back to the renderer through the decoded image.

Affected files:

• media/parsers/jpeg_parser.cc
• media/gpu/vaapi/vaapi_jpeg_decoder.cc

Estimated timestamp from git blame: 2024-04-12

This issue allows a compromised renderer to potentially leak GPU process memory via an out-of-bounds read in the VA-API hardware decoder, aiding in a sandbox escape.

Technical Details

Standard Mojo IPC setup from a compromised renderer establishes a MjpegDecodeAccelerator session. The vulnerability occurs during the parsing of the JPEG bitstream.

When parsing the JPEG_SOF0 marker, media/parsers/jpeg_parser.cc reads the quantization_table_selector for each image component but does not enforce the 0-3 baseline limit:

// media/parsers/jpeg_parser.cc : ParseSOF()
READ_U8_OR_RETURN_FALSE(component.quantization_table_selector);

This unvalidated selector (which can be up to 255) is mapped directly to pic_param_components[i].quantiser_table_selector in media/gpu/vaapi/vaapi_jpeg_decoder.cc and passed to the third-party VA-API driver in the GPU process.

The VA-API driver uses this value to index the 4-element quantization table array (e.g., VAIQMatrixBufferJPEGBaseline). Providing an index > 3 results in a direct OOB read. The OOB memory is treated as quantization matrix data, mathematically embedding the leaked memory into the output decoded image pixels.

Potential Attacker Steps

(Note: These are suggested/potential steps, as the Flapjack LLM agent does not have the ability to run code to verify a working exploit).

1. Gain code execution in a sandboxed renderer process.
2. Bind the viz::mojom::Gpu interface and call CreateJpegDecodeAccelerator() to reach the GPU process.
3. Send a decode request containing a malicious JPEG with the quantization_table_selector set to an out-of-bounds value (e.g., 255) in the SOF0 marker.
4. Read the resulting decoded image buffer and reverse the IDCT/dequantization math to infer the OOB memory contents from the GPU process.

Suggested Fix

Add a bounds check in media/parsers/jpeg_parser.cc within the ParseSOF function to ensure the selector does not exceed the maximum allowed tables:

READ_U8_OR_RETURN_FALSE(component.quantization_table_selector);
if (component.quantization_table_selector >= kJpegMaxQuantizationTableNum) {
  DVLOG(1) << "Invalid quantization table selector";
  return false;
}

Evaluated with Chrome root at commit: 9760e6c70cd33a320713361f17c6dcca85648c0f

Results from Flapjack so far have been promising, but it can be wrong in its deductions. At this time, it does not produce proof of concepts or fuzzer tests. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve Flapjack’s accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.