1844788 - No prompt before opening external protocol if "user entered" (typed, middle-click, or drag and drop)

Status: RESOLVED DUPLICATE of bug 1828334

(Firefox :: Security, defect)

Description

[Umar Farooq [:Puf]]

Attachment: Firefox Bypass.mp4

Firefox Version: [116.0b8] + [117.0a1]
Operating System: [Windows 10] (64-bit)

Run protocols In Firefox No Permission needed.

If We Drag & Drop Link into New Firefox Window

Directly We Can Open External Protocol No Permission Asked

I Have Created Image Drag & Drop

Comment 1

[Umar Farooq [:Puf]]

Attachment: Pufindex.html

Step To Reproduce:

1. Create a Doc1.docx Word File in Your Server

2. Upload Attached PufIndex.html In Your Server

3. Open PufIndex.html

4. Now Open New Firefox Window

5. Now Drag & Drop Box Image To New Firefox Window
   File Execute Done.

Comment 2

[Daniel Veditz [:dveditz]]

Firefox treats "drag and drop" of a link as if it's a manual user action, equivalent to typing it in the address bar. Our logic for this might assume that if the user wants it enough to type it in then we shouldn't annoy them with a prompt. That might not even be a great assumption for literally typed URLs—maybe the user copied it from a scam attempt and doesn't know it will launch an external app.

I agree with the reporter that a prompt would be better in the drag and drop case since the URL is completely invisible, and launching an external app would be surprising. I wouldn't mind prompting in all the current "user initiated" cases and that's probably easier to do rather than treating drag&drop special in just this one instance.

Note that in the reporter's testcase ctrl-click/middle-click on the link doesn't work because the event handler cancels clicks, but you can test the equivalent by right-clicking and opening the link in another tab from the context menu.

I don't know that this rises to the level of a "security bug". Asking the user here is really more of an anti-abuse measure (it's not like users know "oh, that app has a security bug in it and this other one doesn't"). The manual interaction of having to drag and drop is an equivalent slow-down. Either way if you convince the user they want to open something they're going to open it, and ultimately the hypothetical security bug is really in the external app and Firefox can't be responsible for all of them.

Comment 3

[Umar Farooq [:Puf]]

Attachment: New Update POC.mp4

A New POC Technique to Lunch Protocols on Same Page

Comment 4

[Umar Farooq [:Puf]]

Attachment: New Image Drag Firefox.gif

Image POC Technique to Lunch Protocols. Thanks

Comment 5

[Daniel Veditz [:dveditz]]

Gijs, Neil: would it make sense to treat drag and drop of an external protocol differently than dragging a "web" link? Or maybe we should be asking about launching external protocols every time, even if the user manually entered it (since they might not understand what someone told them to type)?

IIRC the external protocol warning was more of an anti-abuse feature and this might not be a security bug. I'll tag it for now though.

Comment 6

[Daniel Veditz [:dveditz]]

bug 1844113 is a near dupe on the drag and drop front, but we might want to add an external protocol warning prompt if the link is dragged within Firefox or if the user types it. But that doesn't protect users who drag to the desktop because Windows handles that.

Comment 7

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #5)

Gijs, Neil: would it make sense to treat drag and drop of an external protocol differently than dragging a "web" link? Or maybe we should be asking about launching external protocols every time, even if the user manually entered it (since they might not understand what someone told them to type)?

The second option here (asking every time we load an external protocol, if it's not done with a web principal), is bug 1828334. As I explained there (bug 1828334 comment 5), not doing so is a relatively recent change, because we made it so people opening these urls by e.g. clicking links on webpages would get 1 prompt instead of 2 (used to be protocol choice prompt + permission prompt, now just permission prompt), and as a side effect that meant such urls when opened directly in the browser (so with system principal) would not prompt at all (because you don't need a permission prompt). We could go back to prompting to confirm (at least the first time such a URL is used) relatively straightforwardly (by not skipping the protocol choice prompt for system principal users; users could still check a checkbox to approve opening such links on a per-protocol basis, and then there wouldn't be prompts in these cases). I asked you there whether you wanted to do that, but I think the question got lost. :-)

Should I assume that you asking the question means we should indeed make that change? And do you want to treat this bug separately or just dupe it over?

A more limited change might be trying to funnel through the original webpage's content principal for opening decisions on these links, which would be more correct but wouldn't fix the copy/paste or manual re-typing case. As you said, I doubt people really understand some of these URLs so I'm not so inclined to spend time on that.

Comment 8

[Daniel Veditz [:dveditz]]

You're right; the only reason to keep this bug separate would be if we wanted to do something only for drag-and-drop. "Drag" seductively seems like it would raise fewer suspicions, but in practice we've seen a TON of real-world copy/paste social engineering and I can't think of any cases of cross-window drag-n-drop attacks in the wild. We should address them together.