1226979 - Incoming "text/plain" dataTransfer items are potentially treated as files under GNU/Linux

Status: RESOLVED DUPLICATE of bug 1800425

(Core :: Widget: Gtk, defect)

Description

[Rafael Gieschke]

0. Use GNU/Linux
1. Open https://ebenda.org/2015/drag-drop/ in Chrome and Firefox
2. Drag and drop the displayed Chrome icon to Firefox
3. See the contents of your /etc/passwd, the web page has read access to it (and potentially to any file on your system when https://bugzilla.mozilla.org/show_bug.cgi?id=1164310 is finished )

Firefox treats file URIs in, e.g., "text/plain" as trusted filenames. It should ONLY treat file URIs in "text/uri-list" as trusted filenames.

Comment 1

[Al Billings [:abillings - ex-MoCo]]

Matt, can you or Kamil repro this?

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed on Ubuntu 14.04.3 with latest release builds of Firefox and Chrome.

Comment 3

[Al Billings [:abillings - ex-MoCo]]

Neil, can you take a look at this?

Comment 4

[Rafael Gieschke]

The PoC can now be found at <https://ebenda.org/2015/drag-drop/spoof.html> (see bug 1226977 comment 24).

I tracked down the problem to <https://hg.mozilla.org/mozilla-central/rev/1c64ec128643>, which fixes bug 229327. It seems like accepting file URIs in text/plain items was intentionally added there to work around an issue with Nautilus only sending them in text/plain items.

The latest change concerning text/uri-list I could find in Nautilus' source is <https://bugzilla.gnome.org/show_bug.cgi?id=314120> (about text/uri-list in clipboard), which is fixed in <https://github.com/GNOME/nautilus/commit/185b32ccbfed514f404860143188156567edce8a>. The GNOME bug mentions that text/uri-list was already supported in drag and drop by Nautilus in August 2005, so I am wondering why the fix to bug 229327 was still necessary in March 2008, though I did not study bug 229327 very intensely.

http://johnlindal.wix.com/xdnd#!dragging-files/ubsnb really seems to be the authoritative reference for dragging files on X11 and only lists text/uri-list as acceptable type. I do not think that any application other than Firefox accepts text/plain file URIs (because this seems quite dangerous and in contrast to the platform's conventions) but did not actively search for them (but, e.g, Chrome does not do so). At least current versions of Nautilus also send text/uri-list items. They react with creating a file "file:---etc-.txt" containing "file:///etc/passwd", when the text/plain from the PoC is dropped on them.

Comment 5

[Rafael Gieschke]

Attachment: 0001-Do-not-map-text-plain-to-application-x-moz-file.patch

This fixes the bug. I do not know if this breaks anything, though. Sadly, I will not have time to run any tests or format a proper HG patch any time soon.

Comment 6

[Rafael Gieschke]

Attachment: 0001-Do-not-map-text-plain-to-application-x-moz-file.patch

Oh, the first version of the patch instead made an "application/x-moz-file" item containing "file:///" (and the corresponding directory in DataTransfer.files) available, which is not much better if bug 1164310 is available :-).

The text/plain -> application/x-moz-file fallback maping has to go away in (at least) one more place, fixed by this updated patch.

Comment 7

[Neil Deakin]

Rafael, did you want someone to look at this patch?

Comment 8

[Rafael Gieschke]

I did not run any regression tests and am not really sure if this breaks anything (and you could probably simplify/remove the "if (!mTargetDragData) {" in line 799 as it will always be true now if I see it correctly) but I think the patch would fix the bug.

So, yeah, would be great if you could have a look on it :-). (I will probably not have time to continue working on it very soon.)

Comment 9

[Al Billings [:abillings - ex-MoCo]]

Neil, this bug has a proposed patch and has been idle for just a couple of days under a year as a sec-moderate. Can you or someone look at this patch and see if we can fix this issue?

Comment 10

[Neil Deakin]

The patch here seems reasonable but it was added to fix a specific issue in bug 229327, so it would need to be tested to ensure that the issues there don't come up.

Comment 11

[Neil Deakin]

Martin, do you think the code being removed by the patch is still something we need to be able to handle? Apparently some file managers only supplied plain text when that code was added, but that may be out of date.

The issue here is that a user can drag text that contains a file uri from another browser (or another instance of Firefox), and we treat it as a real file even though it is only text. We should only be handling it as a file if it really is a dragged file.

(Note that the patch here only removes the special file handling for text/unicode but I think the same issue applies a few lines earlier for text/uri-list as well.)

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Yes, the testcase still works. Neil, what's the issue here? Is it the text/plain -> application/x-moz-file conversion? And if we block that (and any other ones) what does prevent any site to create application/x-moz-file (or different file type) mime type directly?

Comment 13

[Neil Deakin]

The issue is that I can drag some plaintext that says 'file:///etc/passwd' from some other application and drop it on firefox and we will treat it as a file and the web site can read the file's contents. I shouldn't be able to do that.

A web site cannot assign application/x-moz-file at all; setData raises an exception if this is attempted. application/x-moz-file should be used only if there is really a file being dragged, as would be the case when dragging a real file.

Comment 14

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

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 15

[Tom Schuster (MoCo)]

I think this is a duplicate of bug 1800425?

Comment 16

[Martin Stránský [:stransky] (ni? me)]

Yes, looks like dupe of Bug 1800425.