1870384 - firefox URI for iOS Firefox allows to load file URI

Status: RESOLVED DUPLICATE of bug 1850158

(Firefox for iOS :: General, defect)

Description

[James Lee]

We are able to load file URI through firefox URI. Just like I suggested for QR Code Scanning issue https://bugzilla.mozilla.org/show_bug.cgi?id=1868005#c5 firefox URI should only allow http/https.

firefox://open-url?url=file:/

Comment 1

[James Lee]

Bugzilla spitted confirmation error repeatedly and so https://bugzilla.mozilla.org/show_bug.cgi?id=1870385 to https://bugzilla.mozilla.org/show_bug.cgi?id=1870388 should be duplicated.

Comment 3

[James Lee]

*https://bugzilla.mozilla.org/show_bug.cgi?id=1870387

Comment 4

[Andrew McCreight [:mccr8]]

Thanks for clarifying. I was wondering if there was some subtle difference I was overlooking.

Comment 7

[Daniel Veditz [:dveditz]]

If we fix bug 1868005 correctly (an allow-list of web schemes) then this should be a duplicate, but I'm setting depends on so we make sure to check later

Comment 8

[lmarceau]

I confirm this is the same root cause. I have a PR opened that will fix this occurrence as well. Thank you!

Comment 9

[Daniel Veditz [:dveditz]]

Sounds like bug 1850158 is a better thing to depend on, and that the QR code path has some unique behaviors that might not match this bug.

Comment 11

[James Lee]

This works through firefox URI running file URI and nothing to do with QR Code Scanning issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1868005

One fix resolved several different bugs doesn't mean they are duplicate?

Comment 13

[lmarceau]

I had linked the wrong ticket as duplicate sorry, fixed it. It's the same root cause with the same patch as that one, so I see this either as dependent or duplicate. I will let :dveditz determine the exactness of the status of this ticket. Thank you.

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to James Lee from comment #11)

This works through firefox URI running file URI and nothing to do with QR Code Scanning issues like bug 1868005

If this is not using the QR reader then it will not be fixed by bug 1868005 (sanitize URLs from QR reader) but will instead be fixed by bug 1850158 (sanitize deep-link firefox://open-url?url= URLs). Between this bug and bug 1870308 we had mixed up the root-fix bugs.

One fix resolved several different bugs doesn't mean they are duplicate?

That's the basic definition of duplicate, from a bug and CVE point of view. With caveats:

• a "patch" might have more than one "fix". Sometimes related, but separate, issues get addressed at the same time in the same patch. it should be possible to see in the patch that this bit here addresses one bug, and another bit addresses a second bug, and maybe some changes apply to both. That's not what happened here, though: the fix was a simple addition of a call to a preexisting sanitization routine
• a single security bug can often be exploited in lots of different ways. The exploits or PoCs can be unique, clever, and useful. I wouldn't call those PoCs "duplicates" of each other, but in a bug tracking system if they all stem from a single problem then they are duplicate issues. The programmer isn't going to land the same patch multiple times, one for each variant demonstration.
• from a bug bounty point of view, those variant exploits will have varying severities. The number of attack variations doesn't matter, the bounty will be based on the severity of the best attacks

Comment 15

[James Lee]

I can't view bug 1850158 but it's based on running javascript: URI and https://bugzilla.mozilla.org/show_bug.cgi?id=1870384#c8 this would've not fixed if I didn't report before the fix.

I guess I should've waited for the fix before I sent this, I just didn't prefer to do that.

Comment 16

[James Lee]

Probably the initial fix only included to not allow javascript: URI alone.

Comment 17

[Andrew McCreight [:mccr8]]

You've been CC'ed on the bug now by dveditz. As you can see from bug 1850158 comment 10 (that was made before this bug was filed), and less explicitly in earlier comments, an allow-list based approach to limit the schemes to http and https was on peoples' minds for quite some time. I'm sorry that we didn't fix this faster so that you spent time on reporting a known issue.

Comment 18

[James Lee]

I noticed that and that's not the problem, thanks for letting me know. However, we need to check the case that works with open a new tab which is https://bugzilla.mozilla.org/show_bug.cgi?id=1874573