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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A compromised Viz/GPU process can potentially trigger a heap buffer overflow in the browser process via a crafted viz.mojom.CopyOutputResult. When the eye dropper tool captures a snapshot, the browser allocates a destination buffer using nominal dimensions but copies data using an unvalidated stride value. This can lead to a linear heap overflow on the browser process’s PartitionAlloc heap.

Affected files:

• components/eye_dropper/eye_dropper_view.cc
• services/viz/public/cpp/compositing/bitmap_in_shared_memory_mojom_traits.cc

Estimated timestamp from git blame: 2020-04-29

Root Cause Analysis

On ChromeOS, the EyeDropper screen capturer uses DesktopCapturerAsh, which obtains screenshots via ui::GrabWindowSnapshot -> viz::CopyOutputRequest. The response travels from the GPU/Viz process to the browser process as a viz.mojom.CopyOutputResult carrying a BitmapInSharedMemory struct.

During deserialization in the browser process (services/viz/public/cpp/compositing/bitmap_in_shared_memory_mojom_traits.cc), the row_bytes (stride) field of the bitmap is validated via image_info.validRowBytes(data.row_bytes()). However, this Skia function only checks that row_bytes is greater than or equal to the minimum required row bytes for the image width and is properly aligned; it does not enforce an upper bound. The check:

if (mapping_ptr->size() < image_info.computeByteSize(data.row_bytes()))
  return false;

is easily satisfied if a compromised GPU process supplies an appropriately large shared memory region.

This untrusted stride/row_bytes value is subsequently wrapped in gfx::Image and then a DesktopFrameSkia instance. Inside EyeDropperView::ScreenCapturer::OnCaptureResult (components/eye_dropper/eye_dropper_view.cc):

// components/eye_dropper/eye_dropper_view.cc
CHECK_EQ(frame->pixel_format(), webrtc::FOURCC_ARGB);
frame_.allocN32Pixels(frame->size().width(), frame->size().height(), true);
UNSAFE_TODO(memcpy(frame_.getAddr32(0, 0), frame->data(),
                   frame->size().height() * frame->stride()));

Because frame_.allocN32Pixels allocates a tight pixel buffer based on the nominal width and height (allocating exactly width * height * 4 bytes), whereas the subsequent memcpy copies a total of height * stride bytes, a linear heap buffer overflow occurs on the browser’s PartitionAlloc heap.

Potential Trigger Path

Note: These are suggested/potential steps modeled from static analysis; our tooling does not currently run code.

1. A user interacts with a page requesting new EyeDropper().open() with transient user activation.
2. EyeDropperView initializes a screen capturer, resulting in content::DesktopCapturerAsh requesting a window snapshot via ui::GrabWindowSnapshot.
3. A viz::CopyOutputRequest is sent from the browser to the Viz/GPU process, establishing a callback receiver (CopyOutputResultSenderImpl) in the browser.
4. A compromised GPU process intercepts the remote and returns a crafted viz.mojom.CopyOutputResult with a custom, excessively large row_bytes value and a correspondingly sized shared memory backing.
5. The large stride is preserved during deserialization and wrapped into DesktopFrameSkia.
6. The callback in EyeDropperView::ScreenCapturer::OnCaptureResult is triggered. The destination buffer is allocated with width * height * 4 bytes, but memcpy copies height * stride bytes, causing a heap buffer overflow in the unsandboxed browser process.

Suggested Fix

To remediate this issue, the browser should perform a row-by-row copy instead of a single contiguous memcpy when copying the pixel data if the stride does not match the tight standard layout, or enforce that the input stride must match the minimum expected stride for the given dimensions before executing the copy:

// Verify the input stride matches the allocated destination layout
if (frame->stride() != frame->size().width() * 4) {
  return; // Or perform a row-by-row copy
}

Evaluated with Chrome root at commit: a2bea94528f4bd6cc57739c43fa3bb890b8367d3

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.