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

Overview: A race condition exists in the Windows Web Share API where OutputStreamWriteOperation incorrectly inherits from base::RefCounted instead of base::RefCountedThreadSafe. Concurrent releases across the Chrome IO thread and WinRT background threads can trigger a double-free in the browser process. This could potentially be leveraged for sandbox escape and Remote Code Execution.

Affected files:

• chrome/browser/webshare/win/share_operation.cc

Estimated timestamp from git blame: 2020-10-28

Vulnerability Details

Initial logic and parameters for the Web Share API are validated. The IPC routing from the renderer to the browser process and the instantiation of OutputStreamWriteOperation proceed per standard Windows share mechanisms. The core architectural flaw lies in the class inheritance: OutputStreamWriteOperation (in chrome/browser/webshare/win/share_operation.cc) derives from the non-thread-safe base::RefCounted rather than base::RefCountedThreadSafe.

Standard processing applies during the cross-thread handoff between the Chrome IO thread (handling file blob writing) and the OS-managed WinRT background threads (handling the IStreamedFileDataRequestedHandler COM object).

Because base::RefCounted relies on a non-atomic uint32_t for its reference count, concurrent destruction of the scoped_refptr instances on the IO thread and the WinRT thread bypasses thread-safety. Both threads simultaneously execute the out-of-line ReleaseImpl(), non-atomically decrement the counter, and subsequently reload ref_count_ from memory. Both threads observe ref_count_ == 0 and independently execute the destructor, resulting in a double-free in the highly privileged browser process.

Because the frees occur on separate threads, PartitionAlloc routes the pointers into separate ThreadCaches, bypassing FreeList corruption detection and cleanly exposing the memory to overlapping allocations.

Potential Attacker Steps

(Note: These are suggested/potential steps, our tooling agent doesn’t yet have the ability to run code.)

1. Host a malicious page that constructs a file array and invokes navigator.share().
2. Standard UI interaction processing applied (user selects a share target).
3. Exploit overlapping PartitionAlloc ThreadCaches resulting from the concurrent double-free to achieve type confusion on the reallocated object.
4. Hijack control flow (e.g., via writer_delegate_ virtual calls) to achieve arbitrary code execution and a full sandbox escape.

Suggested Fix

In chrome/browser/webshare/win/share_operation.cc, update the class definition to use atomic reference counting:

class OutputStreamWriteOperation
    : public base::RefCountedThreadSafe<OutputStreamWriteOperation> {
...
  friend class base::RefCountedThreadSafe<OutputStreamWriteOperation>;
...

Evaluated with Chrome root at commit: a9cbf6e8b275fe4147435aa905f3b7f5a656f5f0

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.