1422482 - OS username disclosure using downloads manager

Status: NEW

(Firefox :: Downloads Panel, defect, P3)

Description

[Abdulrahman Alqabandi]

Attachment: PoCDL.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

Drag and dropping downloaded files into attacker controlled web page exposes OS username by reading 'text/uri-list' which contains full path to file which includes the OS name.
PoC attached, open and follow instructions.


Actual results:

'text/uri-list' contains OS username (assuming by default the download points to the /Downloads/ folder)


Expected results:

'text/uri-list' should be cleared from containing full path.

Comment 1

[:Gijs (he/him)]

Doesn't seem like we do this for normal files. Paolo, why does this happen for downloads, and can we avoid it?

Comment 2

[:Paolo Amadini]

This is where we currently set the text/uri-list and text/plain types, in addition to application/x-moz-file:

https://dxr.mozilla.org/mozilla-central/rev/f5a1cb52c12e8fbcf2e3b5a675fe2a84d43507a7/browser/components/downloads/content/allDownloadsViewOverlay.js#724-730
https://dxr.mozilla.org/mozilla-central/rev/f5a1cb52c12e8fbcf2e3b5a675fe2a84d43507a7/browser/components/downloads/content/downloads.js#1027-1033

Support for text/uri-list and text/plain was added for Linux in bug 567377. Jan, do you know if there is another approach we could take, maybe extending drag-and-drop support for "application/x-moz-file"?

I don't know the consequences of removing "text/uri-list" for other platforms though. We could instead consider sanitizing or hiding file URLs when dropping them.

Comment 3

[Jan Horak [:jhorak]]

I afraid there's no other way to implement dragging files outside of Firefox, like to file manager.

Comment 4

[Jan Horak [:jhorak]]

We could fix that by stripping the text/uri-list when dropping to the Firefox.

Comment 5

[:Paolo Amadini]

This may be a duplicate of bug 1469083.

Comment 8

[Enzo]

Any news on it ?

I found this thread because the Jupyterlab (used by thousands of people) doesn't recognize it, leading to a behavior similar to 1287823. So it not only unsafe, but it breaks applications too.

Comment 9

[:Gijs (he/him)]

(In reply to Enzo from comment #8)

Any news on it ?

I found this thread because the Jupyterlab (used by thousands of people) doesn't recognize it, leading to a behavior similar to 1287823. So it not only unsafe, but it breaks applications too.

This doesn't really sound like the same issue. This bug is solely about the privacy risk of including URIs for local files when dropping files on web content, whereas bug 1287823 was about broken drags to the desktop from the downloads panel, which can't have anything to do with the web content. You're better off filing a separate issue with more details about how to reproduce the problem you're referring to.

Comment 10

[Fatih Kilic]

Attachment: WIP: Bug 1422482: Only expose file name when dragging a file from downloads

Comment 11

[Fatih Kilic]

I submitted a patch as a WIP, but just want to note one thing, if you enable the newly introduced pref, browser.download.dragUseFileName, it breaks dragging and dropping files to tab bar from downloads. However, it doesn't break dragging and dropping from any other place, despite dragging files from other places also don't include full file paths.

Comment 12

[:Gijs (he/him)]

(In reply to Fatih Kilic from comment #11)

I submitted a patch as a WIP, but just want to note one thing, if you enable the newly introduced pref, browser.download.dragUseFileName, it breaks dragging and dropping files to tab bar from downloads. However, it doesn't break dragging and dropping from any other place, despite dragging files from other places also don't include full file paths.

This would also break dropping the path/URL anywhere else. Can we instead censor file URIs in the data transfer code as far as the content process is concerned?