1767793 - Crash in [@ nsContentSecurityManager::CheckChannel]

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

Note

• Firefox 102.0a1 not affected.

Affected versions

• Firefox 100
• Firefox 101.0b2

Affected platforms

• macOs 10.15

Steps to reproduce

1. Open Firefox with new profile.
2. Open Web Developer Tools/Settings to check the "Enable browser chrome and add-on debugging toolboxes" and "Enable remote debugging" options.
3. Open a new tab
4. Open the Browser Console with cmd+shift+j
5. Execute window.gBrowser.selectedBrowser.browsingContext.loadURI("http://example.com") command.

Actual result

• Firefox crash with:

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/92af557d-f300-4423-b505-6a0f70220504

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0 XUL nsContentSecurityManager::CheckChannel dom/security/nsContentSecurityManager.cpp:1369
1 XUL nsContentSecurityManager::doContentSecurityCheck dom/security/nsContentSecurityManager.cpp:1254
2 XUL mozilla::net::nsHttpChannel::AsyncOpen netwerk/protocol/http/nsHttpChannel.cpp:5743
3 XUL mozilla::net::DocumentLoadListener::Open netwerk/ipc/DocumentLoadListener.cpp:738
4 XUL mozilla::net::DocumentLoadListener::OpenInParent netwerk/ipc/DocumentLoadListener.cpp:928
5 XUL mozilla::net::DocumentLoadListener::SpeculativeLoadInParent netwerk/ipc/DocumentLoadListener.cpp:1022
6 XUL mozilla::dom::BrowsingContext::LoadURI docshell/base/BrowsingContext.cpp:2030
7 XUL mozilla::dom::CanonicalBrowsingContext::LoadURI docshell/base/CanonicalBrowsingContext.cpp:1363
8 XUL mozilla::dom::CanonicalBrowsingContext_Binding::loadURI dom/bindings/BrowsingContextBinding.cpp:4655
9 XUL bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3270

Comment 1

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I could reproduce it on an up-to-date m-c build. It's hitting LoadURI must have a triggering principal

Comment 2

[Daniel Veditz [:dveditz]]

I don't see the docShell version of LoadURI on the crashing stack, and I'm not sure how a release build would get from that returning an error to keeping on with the load and then crashing elsewhere on what looks like a null deref.

Are these steps a common part of smoke tests? are they new? The crashing pattern for this signature shows little spikes, with a few more crashes recently but zero crashes in January through March.

All the crashes are on Mac. Is that just because that's what we all use in testing? Or does this only repro on Mac? There shouldn't be anything mac-specific that I can see in the stack.

Comment 3

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I had tested on Linux; I don't see why this wouldn't apply everywhere.

Comment 4

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I tested on Ubuntu 20 here is the link from crash: https://crash-stats.mozilla.org/report/index/82ffd2a5-707f-4802-abb4-b2e880220510
tested on Windows 10, here is the link from crash: https://crash-stats.mozilla.org/report/index/abd5210d-37cb-4c12-a414-908ac0220510
The crash from this bug came across for me when I verified bug 1760009 on macOS 10.15, that's why I logged a new bug 1767793.

Comment 5

[Daniel Veditz [:dveditz]]

This appears not to crash in Firefox 102, can we call it WFM? In any case, the original crash appears to be due to dereferencing a null TriggeringPrincipal and in 102 Tom's hitting an explicit MOZ_ASSERT() for a null TriggeringPrincipal in a different (earlier?) spot. That's a problem with the calling code in the browser, not the ContentSecurityManager checks

In 102 it still hits an assert, and although that's handled the command you're trying to run probably still doesn't "work". If that's a problem then it's a bug in the calling code that's not setting the TriggeringPrincipal on the channel. That's probably the browsingContext?

Comment 6

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #5)

This appears not to crash in Firefox 102, can we call it WFM? In any case, the original crash appears to be due to dereferencing a null TriggeringPrincipal and in 102 Tom's hitting an explicit MOZ_ASSERT() for a null TriggeringPrincipal in a different (earlier?) spot. That's a problem with the calling code in the browser, not the ContentSecurityManager checks

In 102 it still hits an assert, and although that's handled the command you're trying to run probably still doesn't "work". If that's a problem then it's a bug in the calling code that's not setting the TriggeringPrincipal on the channel. That's probably the browsingContext?

The calling context here is the browser console, where comment 0 inserts arbitrary privileged javascript. Frontend code can't fix this. If we want to fix anything, we need the BrowsingContext::LoadURI to just throw a JS exception rather than crashing. That's a DOM call, so over to them.

Either way I don't see why this is S2 - it's a privileged-user-induced crash.

Timea: out of interest, what led to you reporting this bug?

Comment 7

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

As I said in the comment 4, the crash from this bug came across for me when I verified bug 1760009 on macOS 10.15, that's why I logged this new bug 1767793.

Comment 8

[:Gijs (he/him)]

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA from comment #7)

As I said in the comment 4, the crash from this bug came across for me when I verified bug 1760009 on macOS 10.15, that's why I logged this new bug 1767793.

Sorry for missing that.

Henrik, why are you calling browsingContext.loadURI without a triggering principal in the steps in bug 1760009? Is this crash something marionette/webdriver/... is likely to run into? Can we fix that part on the client side so it provides a principal?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

All of our navigation code that got implemented for Marionette, CDP and WebDriver BiDi is using a triggering principle. See:
https://searchfox.org/mozilla-central/search?q=loadURI&path=remote%2F&case=false&regexp=false

And when I filed bug 1760009 I was inappropriately missing that argument, which lead to a crash (which shouldn't happen even when you have to run through the Browser Console).