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: DataSharingSDKDelegateDesktop performs an unchecked static_cast to DataSharingUI on a WebUIController. A compromised chrome-untrusted renderer can navigate this WebContents to another WebUI, changing the controller type and leading to out-of-bounds memory access in the browser process.

Affected files:

• chrome/browser/data_sharing/desktop/data_sharing_sdk_delegate_desktop.cc
• chrome/browser/ui/webui/data_sharing/data_sharing_ui.h

Estimated timestamp from git blame: 2024-11-12

Summary

A potential type confusion vulnerability exists in the browser process due to unchecked static_cast operations in DataSharingSDKDelegateDesktop. This class manages a hidden WebContents to host chrome-untrusted://data-sharing. If a compromised renderer navigates this WebContents to a different chrome-untrusted:// host, the WebUIController changes to a different subclass. Subsequent SDK calls perform an invalid static_cast, leading to spatial out-of-bounds (OOB) memory corruption and potentially a sandbox escape.

Vulnerability Details

DataSharingSDKDelegateDesktop creates a hidden WebContents and loads chrome-untrusted://data-sharing. It retrieves the WebUIController from this WebContents and casts it to DataSharingUI* using a raw static_cast (e.g., in MaybeLoadWebContents).

In Chromium’s security model, chrome-untrusted:// renderers host untrusted content and are assumed compromisable. Once compromised, the data-sharing renderer can initiate a top-level cross-origin navigation to another untrusted WebUI, such as chrome-untrusted://print/.

Because the process was previously granted request permissions for the entire chrome-untrusted scheme upon the initial commit, ChildProcessSecurityPolicyImpl::CanRequestURL allows this navigation. The cross-origin navigation triggers a process swap, and the new process commits the chrome-untrusted://print/ URL.

Consequently, the WebContents’s WebUIController is replaced with an instance of PrintPreviewUIUntrusted. On a 64-bit architecture, PrintPreviewUIUntrusted is only 16 bytes in size, whereas DataSharingUI is approximately 112 bytes.

DataSharingSDKDelegateDesktop maintains a 1-minute keep-alive for the WebContents. If another SDK call is triggered (e.g., by another click on a tabshare URL) within this window, MaybeLoadWebContents re-executes. Since web_contents_ is non-null, it performs the invalid static_cast on the new controller and calls data_sharing_ui->IsApiInitialized().

Impact

The type confusion leads to spatial OOB memory access on the browser’s PartitionAlloc heap:

1. OOB Read: IsApiInitialized() reads page_handler_ from an offset of approximately 48 bytes, which is past the 16-byte bounds of the object.
2. OOB Write: If the OOB read yields null (e.g., through heap grooming), the code executes data_sharing_ui->SetDelegate(this). This writes a valid DataSharingSDKDelegateDesktop* pointer to the delegate_ member at an offset of approximately 104 bytes.

This OOB write corrupts adjacent heap memory. Because the corruption is spatial and targets a live object (rather than a Use-After-Free), MiraclePtr (BRP) may not mitigate the issue if the attacker grooms the overwritten memory to avoid invalid refcount decrements. This can be leveraged for arbitrary code execution in the browser process.

Potential Reproduction Steps

(Note: These are suggested steps; our tooling has not executed a working proof-of-concept.)

1. From a compromised chrome-untrusted://data-sharing renderer (created via a data sharing action), execute window.location.href = 'chrome-untrusted://print/';.
2. The browser permits the navigation and replaces the WebUIController with PrintPreviewUIUntrusted.
3. Within 60 seconds, trigger a second SDK call (e.g., another tabshare link click).
4. The browser process performs the invalid static_cast and attempts to write to the delegate_ field, corrupting adjacent heap memory.

Suggested Fix

Avoid using raw static_cast on WebUIController objects. Since DataSharingUI defines WEB_UI_CONTROLLER_TYPE_DECL(), you can safely downcast using the GetAs method:

DataSharingUI* data_sharing_ui = 
    web_contents_->GetWebUI()->GetController()->GetAs<DataSharingUI>();
if (!data_sharing_ui) {
  // Handle error: the WebContents has navigated away.
  return;
}

Alternatively, consider adding a WebContentsObserver to DataSharingSDKDelegateDesktop to nullify web_contents_ if it navigates away from chrome-untrusted://data-sharing or if the WebContents is destroyed.

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.