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 potential release-build bounds-enforcement gap in RotateDesktopFrame can allow a heap out-of-bounds write or underflow in the browser process on Windows. When a display-mode or resolution change occurs concurrent with rotated screen capture via the DXGI path, a size divergence between cached and live textures can cause coordinate calculations to bypass debug-only checks. This results in writing screen-pixel bytes to out-of-bounds heap memory via libyuv::ARGBRotate.

Affected files:

• third_party/webrtc/modules/desktop_capture/desktop_frame_rotation.cc
• third_party/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc
• third_party/webrtc/modules/desktop_capture/win/dxgi_texture.cc

Estimated timestamp from git blame: 2016-11-30

Description

There is a potential heap out-of-bounds write (or heap underflow write) in the Windows browser process during WebRTC screen capture. The vulnerability stems from an asymmetry in how bounds are enforced in the capture pipeline. While the standard non-rotated copy path at third_party/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc:247 utilizes DesktopFrame::CopyPixelsFrom(), which performs release-active bounds validation using RTC_CHECK (fatal in release), the rotated copy path relies on RotateDesktopFrame() which uses debug-only RTC_DCHECK statements.

In release builds (NDEBUG), these RTC_DCHECK statements are compiled out. If a mismatch occurs between the cached capture dimensions and the live frame texture dimensions, coordinate calculations can produce out-of-bounds offsets which are then passed directly to libyuv::ARGBRotate() as raw pointers with no runtime safety boundaries.

Root Cause Analysis

1. Debug-Only Bounds Check: At third_party/webrtc/modules/desktop_capture/desktop_frame_rotation.cc:102,108:

   RTC_DCHECK(DesktopRect::MakeSize(source.size()).ContainsRect(source_rect));
   ... 
   RTC_DCHECK(DesktopRect::MakeSize(target->size()).ContainsRect(target_rect));
   

   In production builds, these checks are omitted.

2. Stale vs. Live Size Divergence: DxgiOutputDuplicator caches the unrotated display size (unrotated_size_) at initialization time based on DXGI_OUTPUT_DESC.DesktopCoordinates (at dxgi_output_duplicator.cc:79,147). However, DxgiTexture::CopyFrom() dynamically reads the live texture dimensions per-frame:

   D3D11_TEXTURE2D_DESC desc = {0};
   texture->GetDesc(&desc);
   desktop_size_.set(desc.Width, desc.Height);
   

   (at third_party/webrtc/modules/desktop_capture/win/dxgi_texture.cc:61-63).

3. Integer Underflow and Pointer Arithmetic: During a resolution transition, if a smaller frame is captured before the duplication object is invalidated, DxgiOutputDuplicator::Duplicate() computes source_rect based on the old, larger cached size but executes RotateDesktopFrame() with the smaller live size. Under CLOCK_WISE_90 rotation, RotateAndOffsetRect computes target_rect.left = size.height() - rect.bottom() + offset.x(). When the live height size.height() is smaller than rect.bottom(), this subtraction underflows to a negative value. Pointer arithmetic in GetFrameDataAtPos() then calculates a pointer pointing prior to the heap-allocated destination buffer (at desktop_frame.cc:140), resulting in a heap underflow write via libyuv::ARGBRotate.

Potential Steps to Trigger

Note: These steps are theoretical/potential as our analysis toolchain does not have the capability to execute code.

1. Web content requests screen capture via getDisplayMedia(), and the user permits capture of a monitor rotated by 90 degrees.
2. Screen capture runs in the browser process via ScreenCapturerWinDirectx.
3. Concurrently, a display-mode or resolution change is triggered on the system.
4. If IDXGIOutputDuplication::AcquireNextFrame() returns S_OK with a resized frame texture before signaling DXGI_ERROR_ACCESS_LOST, DxgiOutputDuplicator processes the frame with divergent live vs. cached dimensions.
5. The rotation path calculates a negative target offset, leading libyuv::ARGBRotate to perform a heap out-of-bounds write.

Suggested Fix

1. Harden Bounds Check: Upgrade the RTC_DCHECK statements inside RotateDesktopFrame() in third_party/webrtc/modules/desktop_capture/desktop_frame_rotation.cc to release-active RTC_CHECK assertions, matching the validation behavior in CopyPixelsFrom():

   RTC_CHECK(DesktopRect::MakeSize(source.size()).ContainsRect(source_rect));
   RTC_CHECK(DesktopRect::MakeSize(target->size()).ContainsRect(target_rect));
   

2. Validate Input Dimensions: Inside DxgiOutputDuplicator::Duplicate(), explicitly verify that the live source frame size matches unrotated_size_ prior to entering the rotation loop. If a mismatch is detected, abort capture or re-initialize the pipeline.

Evaluated with Chrome root at commit: d8b226a3be7c9c1ac9240c09e14698866c82e4ac

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.