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

Overview: A logic error in Chrome’s macOS drag-and-drop implementation causes the browser to return the original suggested filename to the OS even when a filename collision occurs and a suffixed file was created. This leads to drop target applications receiving and potentially processing or uploading pre-existing local files instead of the dragged content.

Affected files:

• content/browser/web_contents/web_contents_view_mac.mm
• content/app_shim_remote_cocoa/web_drag_source_mac.mm
• content/browser/download/drag_download_util.cc

Estimated timestamp from git blame: 2019-03-05

Summary

In Chrome for macOS, a logic bug in the handling of ‘promised’ files during drag-and-drop operations leads to an incorrect file path being returned to the drop target application. When a filename collision occurs at the drop destination, Chrome correctly creates a new file with a suffixed name (e.g., file-1.ext) to avoid overwriting existing data. However, it incorrectly reports the original, pre-collision path (file.ext) to the receiving application. This can cause the drop target to process a pre-existing local file instead of the dragged web content.

Root Cause Analysis

The issue is located in WebContentsViewMac::DragPromisedFileTo within content/browser/web_contents/web_contents_view_mac.mm.

// content/browser/web_contents/web_contents_view_mac.mm
bool WebContentsViewMac::DragPromisedFileTo(
    ..., const base::FilePath& file_path, ...,
    base::FilePath* out_file_path) {
  *out_file_path = file_path;                                  // (1)
  ...
  base::File file(content::CreateFileForDrop(out_file_path));  // (2)
  ...
  // The DragDownloadFile constructor may have altered the value of
  // |*out_file_path| if, say, an existing file at the drop site has the same
  // name. Return the actual name that was used to write the file.
  *out_file_path = file_path;                                  // (3) BUG
  return true;
}

1. At step (1), the output path is initialized to the requested path.
2. At step (2), content::CreateFileForDrop (in content/browser/download/drag_download_util.cc) checks if a file exists at the destination. If it does, it generates a suffixed name (e.g., file-1.ext), creates that file, and updates the pointer out_file_path to the new path.
3. At step (3), line 653 explicitly overwrites *out_file_path with the original file_path provided by the caller. This directly contradicts the preceding comment and ensures that the pre-collision path is returned to the Mojo caller (WebDragSource in the app shim process).

WebDragSource then returns this incorrect path to the macOS system (AppKit), which provides it to the drop target application.

Potential Impact

An attacker (or a compromised renderer) can specify a suggested filename for a drag-and-drop operation using the downloadurl metadata. If a user drags this content to a directory already containing a file with that name, the drop target application will receive the path to the user’s pre-existing local file.

If the drop target is an application that immediately processes or uploads the file (such as an email client, a chat application, or a cloud storage upload field), the user may unintentionally disclose the contents of a local file to a third party. While the attacker does not receive the file directly, they can target high-probability filenames (e.g., Resume.pdf, id_card.png, passwords.csv) to increase the likelihood of a collision.

Suggested Reproduction Steps

Note: These steps are based on code analysis and have not been verified with a functional PoC.

1. On macOS, ensure a file named target_file.pdf exists in the Downloads folder.
2. Open Chrome and visit a page that initiates a drag-and-drop download using dataTransfer.setData('downloadurl', ...) with the suggested name target_file.pdf.
3. Drag the item from the web page into the Downloads folder.
4. Observe that Chrome creates target_file-1.pdf in that folder (containing the dragged content).
5. If the drop target is another application (e.g., dragging into a website’s upload area in a different browser window or an electron app), check which file is processed. Due to the bug, the application is likely to receive the path to the original target_file.pdf instead of target_file-1.pdf.

Suggested Fix

Remove line 653 in content/browser/web_contents/web_contents_view_mac.mm to allow the updated out_file_path from CreateFileForDrop to be returned to the caller:

-  *out_file_path = file_path;

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.