Arbitrary local files disclosure in input[webkitdirectory]




2 years ago
4 months ago


(Reporter: qab, Unassigned)


({csectype-disclosure, sec-moderate, stale-bug})

52 Branch
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(Not tracked)




(1 attachment)



2 years ago
Posted file poc.html
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

Note: This was originally part of Bug 1319370 but this turned to be a separate bug deserving of its own report.

1. Open attached PoC
2. Hold down 'enter'
3. If the last used/default folder is 'my documents' (on windows) 
4. All the contents of that folder will be accessible without the explicit permission from the user.

( believe it's the case that this works on more folders in non-windows OS

Actual results:

Once a folder upload prompt appears, IFF a user was holding down the 'enter' key the last used directory/default (if they are within 'My Documents' folder or similar) we are able to trick the user into giving us access to all the files in my documents.

Expected results:

The folder upload button should be blurred from.

Comment 1

2 years ago
Could you please test on non-windows Os?
Comment hidden (typo)
On linux the default directory is 'Desktop'. I agree we should not put the focus on the 'OK' button.
Flags: needinfo?(amarchesini)

Comment 4

2 years ago
I was thinking about a workaround if this was fixed by simply blurring the button and I think there is still a way to do it.

We can theoretically predict where the upload button would appear, with the coordinates at hand we can trick the user into clicking an area on the document repeatedly. After the user is recorded clicking a few times we could insert an input element right where the user is clicking, now since the user is clicking on the coordinates where the upload button will appear, the user could potentially be fooled into pressing the upload file button and disclose all files.

So I think the only safe solution here is to completely disable the button and only enable it once a folder has been selected via click or keyboard keys. Alternatively, always default to a un-uploadable pseudo-folder (for a lack of a better word) similar to Windows' "This PC" location. Hope other operating systems have something similar.
Flags: sec-bounty?
Group: firefox-core-security → core-security
Component: Untriaged → DOM
Product: Firefox → Core
Group: core-security → dom-core-security
Assignee: nobody → amarchesini
Priority: -- → P1
Andrea, please investigate a fix. Thanks.
Comment hidden (off-topic)
Flags: sec-bounty? → sec-bounty-
Comment hidden (off-topic)

Comment 9

2 years ago
(In reply to Al Billings [:abillings] from comment #8)
> Abdulrahman, if it isn't clear. Publicly discussing the details of a
> security bug that we haven't fixed yet is bad form, especially if you never
> put any disclosure date warnings in communications with us. 90 days, at
> least, is the industry standard for people that do put such guidelines on
> disclosure into place. Finding out via twitter and blogs that you've
> potentially 0dayed users is not cool.

I don't think this bug is as severe given Bug 1319370 was fixed, the chances of this affecting any Nightly users is low in my opinion, especially since I disclosed publicly. I definitely should have re-read the bug bounty policy, last I read it it mentioned giving at least 60 days for bugs to be fixed, this was removed. Keep in mind I reported this in Bug 1319370 5 months ago and its been reported here 2 months ago (the 60 I assumed was minimum), so I hope you see I did not have any bad intent just looked like to me I had the right to publicly disclose given everything. Also, I had reported this to Google 8 months and I was eager to write about it.

I will be sure to give you guys a heads up if I ever intend on doing something like this again now that I re-read the policy. Apologies for any inconvenience.
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
The bug is not in DOM. we should implement something better at a FilePicker widget level.
Component: DOM → Widget
This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Keywords: stale-bug
Assignee: amarchesini → nobody
Somebody working on widgets should take it.
Jim, do you know who might be able to work on this?
Flags: needinfo?(jmathies)


2 years ago
Flags: needinfo?(jmathies)
Priority: P1 → P2
I can reproduce. My default was desktop so nothing happened. I think the idea that the user must hold the enter button (triggering repeat) makes this a bit of an outlier. Will find an owner.
Ever confirmed: true


Last year
Duplicate of this bug: 1443762
So unsurprisingly, "some people" are now reporting dupes based on the publicized stuff from qab (also pinned tweet...) as gone over in previous comments. I think we should assume people will try to exploit this if/when convenient to them given it's all public at this point.

Jim, can you please find someone to own this?
Flags: needinfo?(jmathies)

Comment 20

Last year
I am still ashamed for that. My apologies for making things more complicated. FWIW I unpinned the tweet. 
Also, Chrome went with showing a dialog before files are uploaded (along with removing focus from OK button in some OS).
Flags: needinfo?(jmathies)
This is bad UI that could be improved to reduce the opportunities for social engineering, but it does not meet the severity level for the Bug Bounty program.
Group: dom-core-security
Flags: sec-bounty? → sec-bounty-


5 months ago
Duplicate of this bug: 1519506
You need to log in before you can comment on or make changes to this bug.