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 security team.

Overview: The Windows implementation of drag-and-drop lacks a reentrancy guard. A compromised renderer can initiate a second, nested drag-and-drop operation while a first is already in progress, manipulating the OS cursor and dropping arbitrary data (like javascript: URLs) onto targeted overlapping applications or browser UI.

Affected files:

• ui/views/widget/desktop_aura/desktop_drag_drop_client_win.cc
• ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc
• content/browser/web_contents/web_contents_view_aura.cc

Estimated timestamp from git blame: 2025-08-20

Summary

A lack of state validation in DesktopDragDropClientWin::StartDragAndDrop allows a compromised renderer to trigger a nested, reentrant native drag-and-drop loop. This allows an attacker to bypass security checks that ensure the user is actively touching the screen, forcibly move the OS cursor, and execute a data ‘drop’ (including javascript: URLs) at an attacker-controlled screen coordinate that overlaps with the browser’s web bounds.

Technical Details

When a touch-based drag-and-drop is initiated by a web page, the browser calls DesktopDragDropClientWin::StartDragAndDrop. This function checks aura::Env::GetInstance()->is_touch_down() and verifies the cursor is over the source window. It then calls DesktopWindowTreeHostWin::StartTouchDrag(location), which uses the Windows ::SendInput API to forcibly move the OS cursor to the specified location. Finally, it enters the native ::DoDragDrop message loop, which is a blocking, nested run loop.

Critically, WebContentsViewAura::StartDragging instantiates base::CurrentThread::ScopedAllowApplicationTasksInNativeNestedLoop before calling this. This means that while blocked in ::DoDragDrop, the browser UI thread can still process incoming Mojo IPC messages.

Because DesktopDragDropClientWin::StartDragAndDrop does not check if drag_drop_in_progress_ is already true (unlike Ash, which explicitly blocks reentrancy), a compromised renderer can exploit this:

1. The attacker (e.g., via a compromised renderer with an OOPIF) sends a LocalFrameHost::StartDragging IPC to start a touch drag at a safe coordinate P_safe. The browser enters the ::DoDragDrop loop and moves the OS cursor to P_safe.
2. While blocked in ::DoDragDrop, touch release events are intercepted and not dispatched to WindowEventDispatcher. Consequently, the global is_touch_down() state freezes as true.
3. The attacker sends a second LocalFrameHost::StartDragging IPC specifying a target location P_victim (a coordinate within the WebContents bounds, but potentially overlapping a sensitive UI element like the bookmarks bar or another window).
4. The browser processes this second IPC reentrantly. The frozen is_touch_down() state and the current OS cursor position (P_safe) satisfy the security checks in the nested StartDragAndDrop call.
5. StartTouchDrag(P_victim) is called, forcibly moving the OS cursor to P_victim using ::SendInput.
6. The nested ::DoDragDrop fails immediately (Windows OLE disallows nested loops on the same thread). The cleanup code synthesizes a LEFTUP mouse event at P_victim.
7. The outer ::DoDragDrop loop receives this LEFTUP event, interprets it as a user drop at the new cursor location (P_victim), and drops the attacker’s payload (e.g., a javascript: URL).

Impact

An attacker can drop arbitrary payload data (like javascript: URLs, which bypass the FilterURL check specifically to allow bookmarklets) onto any UI element or application that overlaps the WebContents bounds. This can lead to UXSS (saving a malicious bookmarklet) or dropping data onto an overlapping native application.

Proposed Fix

Add a reentrancy guard to DesktopDragDropClientWin::StartDragAndDrop. Similar to Ash’s DragDropController, it should check if a drag is already active and return early:

if (drag_drop_in_progress_) {
  return ui::PreferredDragOperation(
      ui::DragDropTypes::DropEffectToDragOperation(DROPEFFECT_NONE));
}

Evaluated with Chrome root at commit: ff3d2b74fa39431785bd60e51463b08fcc71ee33

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.