1646393 - Web content using a prompt(,) MsgBox can open local file using drag & drop event (drag & drop the prompt(,) selected text into AddressBar or Tab Bar)

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Jordi Chancel]

Attachment: testcase-Local-File-Opened-Displayed.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Steps to reproduce:

-1: Open the Test case in Attachments with Firefox.
-2: Try to Drag and drop the selected text into the Prompt(,) MsgBox.

Actual results:

Firefox loads the local file: File:///etc/passwd

Expected results:

This testcase works on 77.0.1 (64 bits) (Firefox Stable Update) and Firefox Beta also.

(I will upload a Screencast/Video-Demo to the testcase exploitation).

Comment 1

[Jordi Chancel]

Attachment: screencast - video demo.mov

This is the Video-Demo/Screencast of this Security Issue.

Comment 2

[:Gijs (he/him)]

This would load the file but doesn't provide any other pages access to said file, so on top of having to somehow convince users to drag/drop things like this, you'd then need another exploit to actually abuse that file being loaded. So not convinced it's useful to keep this hidden or treat it as a sec bug. Yes, we prevent webpages loading file: links directly to avoid them being able to load them in iframes, or load them in named windows that they can then manipulate - but this only loads as a toplevel, and will load in a different content process to the original webpage (unless that was also loaded from a file: URI), so the possibility of an actual exploit here seems very remote.

Dan, thoughts?

In terms of fixing this, we currently use the triggering principal from the browser for drags from the content, but because the prompt isn't in that document, the triggering principal for the drag/drop there is going to be different. I think we could update the code at https://searchfox.org/mozilla-central/rev/2c1092dc68c63f7bad6da6a03c5883a5ab5ff2ca/dom/base/ContentAreaDropListener.jsm#167-183 to also find the browser content principal for tab-modal prompts, and potentially other items that end up containing user-selectable but page-generated data that live elsewhere (My initial thought was form validation, though it would appear that text in there is not selectable).

Comment 3

[Daniel Veditz [:dveditz]]

I agree. It's a super suspicious thing to do in the first place (if you want to open www.google.com why are you having me drag it instead of acting like a normal web page?), and there are any number of ways to obfuscate what the user is dragging. And in the end the user can clearly see the file:/// in the URL bar so it's not spoofing them about where they ended up.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Adam Vandolder [:avandolder]]

Hi, this came up in today's DOM Core bug triage. Is this something we think is worth addressing or could it be closed instead?