1806171 - Allow file: and content: URI access

Status: NEW

(Fenix :: General, enhancement, P5)

Description

[Kevin Brosnan [Ex-Mozilla]]

Users want to be able to view local files on their device. This includes file:// and content:// URIs.

This needs a comprehensive audit to make sure that Fenix has the same security parameters for local files as Gecko/Desktop Firefox does. Features including CORS and same-origin , chrome and content separation, etc. These audits may be best tackled as separate bugs if there is a qualified developer to perform those audits.

Comment 1

[Pgr]

According to the definitions of the type of bug, this is a defect ("regression, crash, hang, security vulnerability and any other general issue"), because it is regressed basic browsing functionality. Things that used to work, that people and companies rely on, that are part of the standards for some URI types that Firefox used to more fully support, and now no longer does.

Nothing about the definition of "enhancement" ("new feature, improvement in UI, performance, etc. and any other request for user-facing changes and enhancements in the product; not engineering changes") applies here.

I would also argue that the severity is S2, but I leave that to people who are more familiar with this particular bug tracker. Arguments for that can be found in https://github.com/mozilla-mobile/fenix/issues/7546. The existing workarounds are not realistic, they don't really solve anything (really complicated solutions to local browsing which is important precisely as a simplifying process, one that adds reliability to the browsing of static content).

@Kevin Brosnan: regarding your suggested path forward, I fear that "full security audits" will never happen and so I respectfully suggest two different ones:

1. Go back the original commit that caused this serious regression. What problem was it trying to solve? What was the rationale used? How can it be solved without a serious regression like this? Remember that local browsing has been with us since the dawn of web browsers. It didn't suddenly go all insecure. Other browsers do it. Let's solve just the one problem that led to this defect.

2. Provide an about:config-style setting to override this local browsing prohibition. If a user or a company decides it's safer to undergo the risks of local browsing (whatever they are - they should be openly and clearly explained) instead of keeping everyone on the old and insecure Firefox 68, then let them decide, they understand their risks better than Mozilla. I do agree, though, that Mozilla shouldn't do anything risky by default, or that would easily be found unprotected on the devices of the general population.

Thank you! I still have hopes for this defect to get fixed!

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Go back the original commit that caused this

Fenix has a hard separation from Gecko, this has been true since the first commit. Everything that desktop gets for free by being tightly coupled with Gecko needs an API in Geckoview and then that API handled in Fenix.

Provide an about:config-style setting

about:config is a poor fit for controlling features on Fenix because of the hard separation. Making it optional is risky it becomes a one click button to allow Theft of arbitrary files from local system which is a sec-high rated problem. The path forward here is to gather the needed info and implement necessary security changes.

Comment 3

[Chris Peterson [:cpeterson]]

Enhancements should have severity N/A.

Comment 4

[David A. Madore]

How does Chrome / Chromium / the Android native browser (whatever it should be called) handle this issue? Do they also disallow file:/// URLs?

This whole situation is incredibly silly: if I understand correctly, Android's security model is so complex, so badly designed or so broken that somehow “opening a local file” has become a security issue (which it emphatically is not on a PC, so the non-Android Firefox can open file:/// URLs fine), apparently there isn't even an easy fix of allowing opening files in /sdcard or so, and because of this Firefox must prevent users from even opening the files which they themselves downloaded a minute ago. So Firefox can't function as an image viewer or as a PDF viewer (bug #1815739), for which it would otherwise be great, because… opening local files is dangerous‽ This is beyond absurd, especially as PDF viewers for Android are ripe with security issues and using Firefox's pdfjs would probably be a great improvement for everyone. And as the issue is very complex, this bug will never be fixed. But in the mean time, Chrome works fine, and nobody knows why. Am I correctly summarizing the situation, or is there something I missed?

Comment 5

[Glenn Linderman]

How can one access local files on Android without this bug getting fixed? I type in the file:// URL, and it turns into a search with no good matches. That is a stupid response. I didn't want a search, I wanted the local file. I want it local so it will work when I have no available WiFi or cell service.

Comment 6

[Glenn Linderman]

And no, using a local file server is too cumbersone to be considered a solution, because it keeps getting killed in the background.

Comment 7

[Master ? [:masterquestionable]]

    The CVE itself looks much non-sense:
    Malicious app on system may steal certain files from Firefox.

    Actually such app would potentially steal arbitrary files without even involving Firefox... Same for all practical systems.

    Thoughtless operation is incurable security-wise.

Comment 8

[Gildas Lormeau]

Now that SingleFile is officially supported on Firefox for Android [1], a fix for this bug would be appreciated. Today, users can save web pages in HTML format but needs another browser to open it, which is unfortunate.

[1] https://addons.mozilla.org/en-US/android/addon/single-file/

Comment 9

[Master ? [:masterquestionable]]

    More on the main topic:
    https://github.com/MasterInQuestion/talk/discussions/8

    As workaround: setting up a HTTP server can be amazingly easy...
    See: https://bugzilla.mozilla.org/show_bug.cgi?id=1839806#c13
    .
    Though I haven't carefully verified the security implication.
    (whether remote sites could access the "127.0.0.1" URI etc.)

    I believe the issue should have been discussed before.
    And typically only trusted sources ("file://", "localhost" alike) could access them by default:
    With potentially browser flags to allow less secure config.

Comment 10

[Master ? [:masterquestionable]]

    Well... It's not, surprisingly.
    Thoughtlessly doing so may allow remote sites gaining read access to arbitrary files user accessible.

    And currently there exists no config for intervention.

    See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1872502