Closed Bug 1515021 Opened 5 years ago Closed 5 years ago

Assertion failure: aInAndOutListener (can not perform CORS checks without a listener)

Categories

(Core :: DOM: Security, defect)

Product:
Core
Component:
DOM: Security
Version:
66 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla66
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 --- fixed

People

(Reporter: nils, Assigned: jya)

References

Details

(Keywords: assertion, crash, regression)

Crash Data

Attachments

(1 file)

Bug 1515021 - Interrupt steps if shutdown. r?smaug
47 bytes, text/x-phabricator-request
Details | Review 
I think this might not be a security issue, however better be safe than sorry. The following testcase crashes the latest ASAN build of Firefox with this assertiom:
Assertion failure: aInAndOutListener (can not perform CORS checks without a listener), at /builds/worker/workspace/build/src/dom/security/nsContentSecurityManager.cpp:339
AddressSanitizer:DEADLYSIGNAL

Testcase:
<script>
function start() {
        o450=document.createElement('video');
        o461=document.createElement("style");
        o450.setAttribute('crossorigin','anonymous');
        o579=document.createElement('iframe');
        document.documentElement.appendChild(o579);
        window.setTimeout(fun0, 100);
}
function fun0() {
        o979=o579.contentWindow;
        o980=o979.document;
        o450.setAttribute('src','test.ogg');
        o1093=o980.createElement('track');
        o1093.setAttribute('src','x.vtt?0');
        o450.appendChild(o1093);
        o980.write('');
}
</script>
<body onload="start()"></body>


Asan output:
Assertion failure: aInAndOutListener (can not perform CORS checks without a listener), at /builds/worker/workspace/build/src/dom/security/nsContentSecurityManager.cpp:339
AddressSanitizer:DEADLYSIGNAL
=================================================================
==26282==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x14fa6888e882 bp 0x7ffed07684f0 sp 0x7ffed0767cc0 T0)
==26282==The signal is caused by a WRITE memory access.
==26282==Hint: address points to the zero page.
    #0 0x14fa6888e881 in ~nsCOMPtr_base /builds/worker/workspace/build/src/obj-firefox/dist/include/nsCOMPtr.h:328:7
    #1 0x14fa6888e881 in DoContentSecurityChecks /builds/worker/workspace/build/src/dom/security/nsContentSecurityManager.cpp:389
    #2 0x14fa6888e881 in nsContentSecurityManager::doContentSecurityCheck(nsIChannel*, nsCOMPtr<nsIStreamListener>&) /builds/worker/workspace/build/src/dom/security/nsContentSecurityManager.cpp:824
    #3 0x14fa5f8252de in AsyncOpen2 /builds/worker/workspace/build/src/netwerk/base/nsBaseChannel.cpp:679:7
    #4 0x14fa5f8252de in non-virtual thunk to nsBaseChannel::AsyncOpen2(nsIStreamListener*) /builds/worker/workspace/build/src/netwerk/base/nsBaseChannel.cpp
    #5 0x14fa678f3546 in operator() /builds/worker/workspace/build/src/dom/html/HTMLTrackElement.cpp:325:23
    #6 0x14fa678f3546 in mozilla::detail::RunnableFunction<mozilla::dom::HTMLTrackElement::LoadResource(RefPtr<mozilla::dom::WebVTTListener>&&)::$_0>::Run() /builds/worker/workspace/build/src/obj-firefox/dist/include/nsThreadUtils.h:546
    #7 0x14fa5f5d28e5 in mozilla::SchedulerGroup::Runnable::Run() /builds/worker/workspace/build/src/xpcom/threads/SchedulerGroup.cpp:299:32
    #8 0x14fa5f60fd28 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1157:14
    #9 0x14fa5f618add in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:468:10
    #10 0x14fa608a1adf in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/workspace/build/src/ipc/glue/MessagePump.cpp:88:21
    #11 0x14fa607940ae in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:314:10
    #12 0x14fa607940ae in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:307
    #13 0x14fa607940ae in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:289
    #14 0x14fa6997ea93 in nsBaseAppShell::Run() /builds/worker/workspace/build/src/widget/nsBaseAppShell.cpp:137:27
    #15 0x14fa6e3f2c4e in XRE_RunAppShell() /builds/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:915:20
    #16 0x14fa607940ae in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:314:10
    #17 0x14fa607940ae in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:307
    #18 0x14fa607940ae in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:289
    #19 0x14fa6e3f1c9e in XRE_InitChildProcess(int, char**, XREChildData const*) /builds/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:753:34
    #20 0x560f3b437864 in content_process_main /builds/worker/workspace/build/src/browser/app/../../ipc/contentproc/plugin-container.cpp:49:28
    #21 0x560f3b437864 in main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:265
    #22 0x14fa832afb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #23 0x560f3b35ceec in _start (/home/nils/fuzzer3/firefox/firefox+0x2deec)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /builds/worker/workspace/build/src/obj-firefox/dist/include/nsCOMPtr.h:328:7 in ~nsCOMPtr_base
==26282==ABORTING
another testcase in attachment 9032154 [details]
Group: core-security → dom-core-security
The testcase in bug 1515059 attachment 9032154 [details] is dead simple. Why didn't our CI pick up this assertion before? Surely we have tests for HTMLTrackElement.

jya: any ideas? you landed a change to HTMLTrackElement Dec 14 in bug 1443429 (although that could be coincidental)

With a bug collision on the 18th maybe we should be looking for some more recent change elsewhere. Jason: do we have enough ASAN builds around to do a quick bisection?
Flags: needinfo?(jyavenard)
Flags: needinfo?(jkratzer)
(In reply to Daniel Veditz [:dveditz] from comment #3)
> The testcase in bug 1515059 attachment 9032154 [details] is dead simple. Why
> didn't our CI pick up this assertion before? Surely we have tests for
> HTMLTrackElement.
> 
> jya: any ideas? you landed a change to HTMLTrackElement Dec 14 in bug
> 1443429 (although that could be coincidental)
> 
> With a bug collision on the 18th maybe we should be looking for some more
> recent change elsewhere. Jason: do we have enough ASAN builds around to do a
> quick bisection?

I landed a change as the code was dispatching event and modifying the DOM while in stable state.

This is the issue I fixed.

All the code does is create the xpcom nsIblah object outside the stable state. The code flow would be similar
Flags: needinfo?(jyavenard)
this is a release_assert, at best DoS, not a security one.
I reverted the changes of bug 1443429, and as expected the issue can still be reproduced
The testcase bisects to:
> Start: 9717507a9877f6c428b812c20d29f56f87257408 (20181213224257)
> End: f758b51496862ab70ec46c427328cf44503cf750 (20181214054322)
> Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9717507a9877f6c428b812c20d29f56f87257408&tochange=f758b51496862ab70ec46c427328cf44503cf750
Flags: needinfo?(jkratzer)
Tim, any chance this is a result of the UA widget change in bug 1511130? See also bug 1506300.
Flags: needinfo?(timdream)
attachment 9032154 [details] still crashes the tab when I flip dom.ua_widget.enabled to false. This is unlikely related to UA Widget front-end. Is it possible to reduce the regression range further? I believe mozregression can identify the offending push.
Flags: needinfo?(timdream)
INFO: Last good revision: d986d2da3bed7269fafe5106359b50af5f4b63c7
INFO: First bad revision: 1ae2a252d3e81d1b52fe2ef3e49c51f8c2344f1d
INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d986d2da3bed7269fafe5106359b50af5f4b63c7&tochange=1ae2a252d3e81d1b52fe2ef3e49c51f8c2344f1d

Looks like bug 1443429 is the lucky winner after all.
Blocks: 1443429
Group: dom-core-security
Crash Signature: [@ nsContentSecurityManager::doContentSecurityCheck ]
Has Regression Range: --- → yes
status-firefox64: --- → unaffected
status-firefox65: --- → unaffected
status-firefox-esr60: --- → unaffected
Keywords: assertion, crash, regression
Not sure what to make of comment 6 in that light, however.
Assignee: nobody → jyavenard
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b77b6244ebc9
Interrupt steps if shutdown. r=smaug
https://hg.mozilla.org/mozilla-central/rev/b77b6244ebc9
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox66: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Flags: sec-bounty?

This does not appear to have been an exploitable problem.

Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: