1945390 - 135.0b9 "Could not load the image" with background-image: url("file:///C:/Tools/FF/FFbkgnd01.jpg") !important;

Status: REOPENED

(Core :: Security: Process Sandboxing, defect, P3)

Description

[careca]

Attachment: screenshot - 02022025-1827.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Used
background-image: url("file:///C:/Tools/FF/FFbkgnd01.jpg") !important;
in usercontent.css
Path exists, this works with version 133.
Simply installed the beta 135.0b9

Actual results:

Image did not load and in developer tools, it said: "Could not load the image" in the tooltip when hovering with mouse over the line.

Expected results:

Load the image into the background, like it still does in the regular, non-beta desktop version of firefox, 133.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Inspector' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bfa185b0b771c9db7f89af5ebcd681b2cc5d8f14&tochange=4cb3a473e63ce257cd044460cda002f2b6923bab

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:bobowen, since you are the author of the regressor, bug 1900175, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Donal Meehan [:dmeehan]]

Bug 1403931 enabled this for release in Fx134

Comment 5

[Bob Owen (:bobowen)]

This is failing now because we've removed read access from most of the filesystem in the content process.
In theory I think this would still work if the file referenced was somewhere still readable, for example under the chrome directory in the Firefox profile where the userContent.css file is. But I don't think we can guarantee that will always work. Eventually we should probably be opening these user CSS files in the parent and passing down the handle/FD.
However, I'm slightly surprised that we allow file URLs to be used in content processes (other than the file content process) like this.

dholbert - is this something special about userContent.css or would it always currently be allowed? I feel that this is something that should probably be blocked in the layout code unless the CSS is being processed for a file: URL page.
I'm not sure what other options to achieve the same thing are, I imagine you could do this through an extension.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

userContent.css gets loaded in all processes because it applies to all content pages. That said, this functionality is deprecated, and I think asking the users of this feature to put the images in a content-accessible path is a reasonable ask.

Comment 7

[Bob Owen (:bobowen)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

userContent.css gets loaded in all processes because it applies to all content pages. That said, this functionality is deprecated, and I think asking the users of this feature to put the images in a content-accessible path is a reasonable ask.

The only issue is that I think we will be working towards removing all of the remaining exceptions for read access to the filesystem.
What would happen if you put a file: URL in a normal CSS file?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Not sure what the question is, it gets requested via necko the same way as images and other subresources.

Comment 9

[Bob Owen (:bobowen)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Not sure what the question is, it gets requested via necko the same way as images and other subresources.

It's not the mechanics of getting the actual bytes I'm thinking about.
http(s) pages are blocked from linking to, framing etc. file: URL pages for security reasons, is this not the case for CSS files?

Comment 10

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: simple testcase that tries to show ubuntu logo from local filesystem

What would happen if you put a file: URL in a normal CSS file?

Here's a demo just to have a live testcase to demonstrate what happens for this in regular web content, for reference. This testcase attempts to load a file:/// URI where Ubuntu usually has a logo image. If I view this testcase on my local filesystem (using a file URI), it succeeds; but when I view the testcase on a web server, the load gets blocked, with:

Security Error: Content at http://localhost:8999/test.html may not load or link to file:///usr/share/plymouth/ubuntu-logo.png. 

(In my case, I was testing this using a web server running on http://localhost:8999/ but when you load this Bugzilla-hosted version it'll show the bugzilla attachment URI.)

It seems to be blocked before the regression range and even as far back as Nightly 2012-03-01 (a random old nightly that I tested).

This was mostly a tangent, just to illustrate the point that file:/// URIs are already pretty thoroughly blocked from web content (independent of the changes in bug 1900175).

Comment 11

[Emilio Cobos Álvarez (:emilio)]

http(s) pages are blocked from linking to, framing etc. file: URL pages for security reasons, is this not the case for CSS files?

Mostly? It depends on the originator of the request. In this case, userContent.css is privileged, so it can access file:// resources. Note that the resource we're requesting in comment 0 is not a CSS file, but a regular image.

Comment 12

[Bob Owen (:bobowen)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

http(s) pages are blocked from linking to, framing etc. file: URL pages for security reasons, is this not the case for CSS files?

Mostly? It depends on the originator of the request. In this case, userContent.css is privileged, so it can access file:// resources. Note that the resource we're requesting in comment 0 is not a CSS file, but a regular image.

OK, thanks both.
As you say for the moment putting the resources under the same dir as the userContent.css seems reasonable.
If we're going to continue to want this to work this way going forward, we're going to have to move from opening file: URIs in the content process and instead open them in the parent or possibly another utility process.
That probably is something we want to do anyway, but good to know it would block removing some of the remaining read access for content processes.

Comment 13

[careca]

Placing the image in the chrome folder, as suggested, works.
Thank you.

Comment 14

[Bob Owen (:bobowen)]

(In reply to careca from comment #13)

Placing the image in the chrome folder, as suggested, works.
Thank you.

Thanks for confirming.

Comment 15

[Bob Owen (:bobowen)]

I meant to leave this open as there is something we'll need to address at some point.

Comment 16

[Tom Schuster]

Do note that the about:newtab's Content-Security-Policy does not allow file: as an img-src, but it is allowed anyway, because we have a long standing issue with file: URLs not being considered subjectToCSP at all. In the future I would like us to have fewer blanket exemptions to CSP like this.

Comment 17

[careca]

From all of your comments i am taking the impression this "fix" of placing the image in the chrome folder, is not gonna last long.

Comment 18

[Bob Owen (:bobowen)]

(In reply to careca from comment #17)

From all of your comments i am taking the impression this "fix" of placing the image in the chrome folder, is not gonna last long.

If the intention is (as indicated in comment 11) for userContent.css to be privileged to load file: URLs then I'll need to fix that before I remove the read exception from the chrome folder in the sandbox policy.

However from comment 16, it seems that it might become subject to other security policies aside from process sandboxing at some point.
I don't know if userContent.css would be given exceptions for that.
In general userContent.css is deprecated, so we can't guarantee maintaining all current functionality and I wouldn't rely on it for anything critical.

Comment 19

[Frederik Braun [:freddy]]

Aligning with coding practices and security guidance as the software evolves is part of normal development practices. Indeed, we won't guarantee support for internal APIs.

But if you register the image in a chrome folder such that it can be loaded through a resource:/ or chrome:/ URL, then it should continue to be possible to load for quite a while. After all, this is how we load our internal images as well. E.g. the settings icon in the bottom right of about:newtab is using an CSS background-image with the URL chrome://global/skin/icons/settings.svg.