1338637 - (CVE-2021-23956) Arbitrary local files disclosure in input[webkitdirectory]

Status: RESOLVED FIXED

(Core :: Widget, defect, P2)

Description

[Abdulrahman Alqabandi]

Attachment: 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

[Abdulrahman Alqabandi]

Could you please test on non-windows Os?

Comment 2

[Abdulrahman Alqabandi]

(In reply to Abdulrahman Alqabandi[test] from comment #1)
> Could you please test on non-windows Os?

ops

Comment 3

[Andrea Marchesini [:baku]]

On linux the default directory is 'Desktop'. I agree we should not put the focus on the 'OK' button.

Comment 4

[Abdulrahman Alqabandi]

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.

Comment 5

[Andrew Overholt [:overholt]]

Andrea, please investigate a fix. Thanks.

Comment 6

[Andrew McCreight [:mccr8]]

It looks like this has been posted publicly in http://leucosite.com/Chrome-Firefox-Edge-Local-File-Disclosure/

Comment 7

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

(In reply to Andrew McCreight [:mccr8] from comment #6)
> It looks like this has been posted publicly in
> http://leucosite.com/Chrome-Firefox-Edge-Local-File-Disclosure/

So much for the bounty then.

Comment 8

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

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.

Comment 9

[Abdulrahman Alqabandi]

(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 10

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

I do not believe our client bounty policy has ever specified 60 days. I'd love for you to show me where it has. Possibly you are confusing Mozilla with Google or someone else. We haven't substantially changed the wording of the security policy recently, having only done minor edits within the last year. 

You should not make "assumptions" about a 60 day policy. Mozilla does not have a 60 (or 90 or 120) day disclosure policy and never has. Sometimes reporters come to us and state "I will disclose this bug in x days" and we try to act with this knowledge. We do not have a policy of "If we don't fix this in 60 days, you should tell the world about it in detail." I have no idea why you thought publicly disclosing this was a good idea at all based on anything we've ever said to you. If we had known that you thought that after 60 days, you were ok to just open this up to the world, we might have acted differently. It kind of burns bridges with us to do things like this with ZERO communication on your part to us. Even giving us a heads up would have allowed us to have a discussion with you about your assumptions and ours.

In any case, this bug isn't fixed. It is hidden as a security issue. You just wrote a detailed blog post about it. This isn't about users of our nightly builds. This is about the fact that this is a security issue affecting *all* of our users, potentially. 

If you wanted to write a post about an unfixed bug, you would be better served to either ask in the bug if we see any issues doing so or emailing us at [e-mail], rather than handing the world a security issue with details when it isn't fixed.

I really don't care when you reported to Google or Microsoft. That is Google and Microsoft's business, not ours. Their policies and responses are not ours. 

What I see here is a 60 day old bug that is now public when we're about to ship a release in several days so we can't fix it in time for Firefox 53 without making it an emergency. As a moderate issue about data disclosure, we're not going to do that because the costs are too high and the impacts too great.

Comment 11

[Abdulrahman Alqabandi]

Again, this bug is 5 months old originally reported in Bug 1319370. But yes I did confuse the 60 day policy thing that came from Google not you. I also was under the impression that Mozilla did not care about public disclosure, all you ask is sufficient time to fix, I believe after 5 months that is sufficient. 

From https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/ Q&A:

The question is: "If I report the bug directly to you, do I have to keep the bug confidential and not publish information about it in order to receive a reward?"

Mozillas answer: "No. We’re rewarding you for finding a bug, not trying to buy your silence... "

As I write this I realize this may be only applicable for website flaws but this was not clear to me before.

I'm really surprised by your reaction to this and am sad that you took this as a bridge burner. I hope you reconsider as I have what I think is a good track record (few hickups), there is even an SOP bypass that is 4 months old and I do not plan on publicly disclosing anytime soon and have been more than patient, plenty other bugs in the same situation. My mistake was communication, but I honestly thought you guys were so busy that I did not want to bother about a less severe bug.

Comment 12

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

(In reply to Abdulrahman Alqabandi from comment #11)

> From https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/ Q&A:

That's not the bounty program that covers Firefox or our client software. That's the one for our websites, which is why it says "Web Application" on the top. The client program is at https://www.mozilla.org/en-US/security/client-bug-bounty/  The text is largely the same but you should be sure you're referring to the appropriate program since details do differ between them.

And, no, we aren't "buying silence" but we also expect people not to 0day users, especially with zero communication with us that they are about to do so. 

Perhaps the bounty committee as a whole with disagree with my decision and still pay a bounty on this issue. 

> I'm really surprised by your reaction to this and am sad that you took this as a bridge burner. I hope you reconsider as I have what I think is a good track record (few hickups), there is even an SOP bypass that is 4 months old and I do not plan on publicly disclosing anytime soon and have been more than patient, plenty other bugs in the same situation. My mistake was communication, but I honestly thought you guys were so busy that I did not want to bother about a less severe bug.

It isn't a "bridge burner" in the sense that you're out of the bounty program or something. It is in the fact that we pay attention to the behavior and interactions with security researchers and do note which ones work well with us and which ones, for example, post unfixed bugs in public without telling us. You can still continue to work with us. Up until now, you've been fairly well regarded on our team for the work you've done. The relationship isn't irreparably damaged but this was not a good surprise on a Friday morning. 

Further discussions should be held by email if necessary at [e-mail].

Comment 13

[Andrea Marchesini [:baku]]

The bug is not in DOM. we should implement something better at a FilePicker widget level.

Comment 14

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

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.

Comment 15

[Andrea Marchesini [:baku]]

Somebody working on widgets should take it.

Comment 16

[Andrew McCreight [:mccr8]]

Jim, do you know who might be able to work on this?

Comment 17

[Jim Mathies [:jimm]]

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.

Comment 19

[:Gijs (he/him)]

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?

Comment 20

[Abdulrahman Alqabandi]

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).

Comment 21

[Daniel Veditz [:dveditz]]

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.

Comment 23

[:Gijs (he/him)]

Looks like on Windows you can require interaction with the view in the modal dialog before the OK button is enabled by passing FOS_OKBUTTONNEEDSINTERACTION (which is listed as one of the relevant options on the doc site, but with no explanation, so I wonder when that got added and on what OSes it's supported...). That seems to wfm on win10.

However, even Edge does not appear to use it; it instead prompts for confirmation before uploading, as does Chrome - with a dialog that then defaults to [Cancel] (despite the styling of the dialog buttons suggesting that "Upload" is the default, which is... weird.)

Dan, what do you think about doing the same?

Comment 25

[:Gijs (he/him)]

Paul, do you have cycles to look at adding a confirmation dialog using the tab-modal dialog infrastructure to mimic Edge/Chrome? Looks like somewhere like https://searchfox.org/mozilla-central/rev/e1d1f043957191616721b9e8bf811c0aab8a203a/dom/html/HTMLInputElement.cpp#483 would work?

Comment 26

[Paul Zühlcke [:pbz]]

Attachment: Bug 1338637 - Ask user for confirmation before folder upload. r=gijs

Comment 27

[Paul Zühlcke [:pbz]]

Attachment: Bug 1338637 - Added test for folder upload confirmation prompt. r=gijs

This also fixes an issue where MockFilePicker wouldn't set the mode correctly,
which caused it to always use "modeOpen". For this test we need to pass
"modeGetFolder" in order for the prompt to show.

Depends on D95324

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5c29fd30af97
Ask user for confirmation before folder upload. r=Gijs,geckoview-reviewers,agi,baku
https://hg.mozilla.org/integration/autoland/rev/5bddcb99f650
Added test for folder upload confirmation prompt. r=Gijs

Comment 29

[Razvan Maries]

Backed out for perma failures.

Push with failure: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=LM0CGoNbT1Kf1udXtFq_Nw.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=5bddcb99f650063907888fe944ac6c3cc7e7ba69

Log: https://treeherder.mozilla.org/logviewer?job_id=321917169&repo=autoland&lineNumber=5103

Backout: https://hg.mozilla.org/integration/autoland/rev/72c8c0774cee0aac6084838f837186f904f7bb52

Comment 30

[Paul Zühlcke [:pbz]]

Attachment: Bug 1338637 - Updated webkitdirectory test to handle confirm prompts. r=gijs

Depends on D96526

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fa598dea0903
Ask user for confirmation before folder upload. r=Gijs,geckoview-reviewers,baku
https://hg.mozilla.org/integration/autoland/rev/9515d8916527
Added test for folder upload confirmation prompt. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/7b898a8dac3c
Updated webkitdirectory test to handle confirm prompts. r=Gijs

Comment 32

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/fa598dea0903
https://hg.mozilla.org/mozilla-central/rev/9515d8916527
https://hg.mozilla.org/mozilla-central/rev/7b898a8dac3c

Comment 33

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 34

[Frederik Braun [:freddy]]

Attachment: advisory.txt