1644844 - There is no way to register data: URI sheets with security.cancel_non_local_loads_triggered_by_systemprincipal enabled

Status: RESOLVED WONTFIX

(Core :: DOM: Security, enhancement)

Description

[tustamido]

With security.cancel_non_local_loads_triggered_by_systemprincipal = true (currently default to false), nsIStyleSheetService throws an error when trying to register data: URI sheets.

Bug 1613609 provided a workaround if we set channel.localInfo.allowDeprecatedSystemRequests = true, but nsIStyleSheetService.loadAndRegisterSheet only accepts nsIURI and sheet origin (agent/user/author).

The patch landed in bug 1613609 whitelists nsIContentPolicy.TYPE_STYLESHEET, so shouldn't data:text/css be allowed too? At least there should be an option to bypass this without loosening security with security.cancel_non_local_loads_triggered_by_systemprincipal = false.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

So two things, out of curiosity:

• What are you using/planning to use nsIStyleSheetService for? (Honest question, I'm curious because I've been pondering with simplifying it and if external consumers are using it it'd be great to know what for)
• Are the relevant APIs in DOMWindowUtils (DOMWindowUtils::LoadSheet and such) also affected? I'm moderately sure that the extensions code uses this one, so if it also is, it should be fixed as well before turning on.

Other than that, this looks more like DOM: Security stuff than CSS stuff per se, though I'm happy to help here if I can.

Comment 2

[tustamido]

Hi,

Well, you guys may not like to hear this, but let's say I'm sorta still using the old Stylish and some other legacy addons. I use resource:// urls for UserStyles, these are fine, but editor's instant preview uses data: URI. Code is hosted here (I don't know if it's fine to paste external links here, it's just to answer you with more context): https://github.com/xiaoxiaoflood/firefox-scripts/blob/master/chrome/utils/styloaix/edit.js#L165-L168

I also use nsIStyleSheetService with data:text/css in other scripts, but I can easily make chrome/resource urls for them, the real problem is only with the editor's preview.

And yes, windowUtils.loadSheet is also affected.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Ok, so it seems like if loadSheet is affected probably this needs to be fixed there as well, and the fix would probably be similar.

Comment 4

[Frederik Braun [:freddy]]

Thank you for reaching out!
The issue with allowing data URLs being passed around, is that it's hard to track down where content originates from and ends up providing stepping stones for sandbox escapes. Especially when they are passed around across trust boundaries (e.g. process boundary, system/content principal boundary).

I think it would be best if you found a way to use one of the trusted URI schemes:
We're currently allowing stylsheet loads from the file URI scheme, precisely because of files like userContent.css. So I suggest you want to start using temporary files on disks and load them through file URIs.

The list of currently trusted shemes is moz-extension, resource, chrome, jar and file. I would like to encourage you to try using one of those. If filedoesn't work, I'd explore registering a moz-extension. But I don't whether there a any internal APIs you can use. Note that it's possible that blob and data will make it to the allow list temporarily for certain content-types (e.g., nsContentPolicyType::TYPE_STYLE), but I wouldn't rely on that. Long term, I do not intend to allow data+TYPE_STYLE, but I'm fully aware that disallowing this right now will break existing supported functionality (e.g., devtools style editor), so we'll find a middle-ground between laxer restrictions and fixes to loadSheet functions

I hope that helps you resolves this issue. Let me know what you think.

Comment 5

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

Set release status flags based on info from the regressing bug 1613609

Comment 6

[Frederik Braun [:freddy]]

All things considered, I'm willing to help you find out how to make your thing work in Firefox, but this is not a supported configuration and I will continue to be here for your follow-up questions

The DevTools (and probably other CSS-related failures) will be tracked in bug 1641192. So I am marking this as WONTFIX and will remove the regression fields, so we don't end up tracking something we're not going to fix for a specific release. Especially, since the restriction is disabled by default.

Comment 7

[tustamido]

I really appreciate your help, especially for something that is not officially supported. Others would shrug their shoulders.

I would like to avoid abusing file i/o, since instant preview needs to track each char typed. I'm using 500ms timeout, but for large styles I think it's still overload. Even data: URI is not the cheaper way. Ideally I would like to use the same way DevTools does in its style editor instant preview, but I don't know how it works.

Comment 8

[Frederik Braun [:freddy]]

Short term, we're likely going to allow data: for styles and Bug 1639478 talks about minting blob URLs that in the parent process, so we can disallow them eventually.