<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Comment 2

•

5 years ago

•

Edited

It looks like the use and free happen entirely with a call to ClientSource::SnapshotState().

The free happens on line 687 of: MOZ_TRY(MaybeCreateInitialDocument());.

The use happens in that function two lines later: return SnapshotWindowState();

Somehow we end up in nsGlobalWindowInner::EnsureClientSource(), which destroys the client source here:

if (!clientPrincipal || !clientPrincipal->Equals(mDoc->NodePrincipal())) {
  mClientSource.reset();
}

...but I think mClientSource is this so we end up in trouble.

This part of SnapshotState() changed recently in bug 1544522, so maybe this is a regression from that?

Component: DOM: Core & HTML → DOM: Service Workers

Comment 3

•

5 years ago

Could you take a look please, Jens? Thanks.

Flags: needinfo?(jstutte)

Updated

•

5 years ago

Summary: heap-use-after-free in [@ nsAutoOwningThread::AssertCurrentThreadOwnsMe] → heap-use-after-free while running ClientSource::SnapshotState()

Comment 4

•

5 years ago

Tyson, I noticed you marked 83 as affected. Is that correct? (I'm just wondering precisely about that, because that means this wouldn't be regression from bug 1544522, which landed in 84). Thanks.

Flags: needinfo?(twsmith)

Tyson Smith [:tsmith]

Reporter

Comment 5

•

5 years ago

This has been seen twice by the fuzzers and the first time was with m-c 20201008-9f3fcb6752b4

Flags: needinfo?(twsmith)

Updated

•

5 years ago

Flags: needinfo?(jstutte)

Comment 6

•

5 years ago

•

Edited

So this seems to be exactly the situation we added this MOZ_DIAGNOSTIC_ASSERT for that then got removed as part of bug 1544522 but that was not obvious to us when we removed it.

The bottom line seems to be, that we cannot safely call GetDocument() from within ClientSource, as this can destroy our this.

ClientSource::MaybeCreateInitialDocument() is actually not even needing the context of ClientSource, it could be a static function - but it cannot be called by any ClientSource function. I see three possible ways forward here:

Just drop MaybeCreateInitialDocument() and trust/ensure that ClientSource::SnapshotState() can deal with a missing document
Move the GetInfoAndState operation out of ClientSource into some other object we know will survive (InnerWindow ?)
Ensure, that someone already called a static variant of MaybeCreateInitialDocument() before we dispatch the GetInfoAndState message (that sounds fragile to me)

I would probably go for 1), which might have side effects yet to discover, though.

Flags: needinfo?(bugmail)

Comment 7

•

5 years ago

Talking yesterday with Andrew, we want to give 1) a try. Following are some random notes from looking a bit closer at the code:

Looking for places in ClientSource (and called code) that might rely on the existence of a document, I found a few calls to nsPIDOMWindowInner::HasActiveDocument(). Interestingly, this function does not check what it claims to check, it nowadays just calls nsPIDOMWindowInner::IsCurrentInnerWindow() (this was not always the same and has been changed here). So the use of this function somewhere in ClientSource needs not an initialized document as a prerequisite. In fact, I propose to substitute it with IsCurrentInnerWindow() in order to reduce ambiguity.

Assignee: nobody → jstutte

Flags: needinfo?(bugmail)

Comment 8

•

5 years ago

So just removing ClientSource::MaybeCreateInitialDocument() is not enough, this leads to some deterministic failures. And the failure of service-workers/service-worker/fetch-event-handled.https.html reproduces also locally, but only after a dry start, not after a reload in an open browser window.

There is a difference in the log files, that after investigation indicate that in the failing case in the content process during CacheStorage::HasStorageAccess() the mGlobal is not null but it is also also not of type nsPIDOMWindowInner.

Comment 9

•

5 years ago

Moving the work over to bug 1675916.

Updated

•

5 years ago

Depends on: 1675916

Comment 10

•

5 years ago

Hi Tyson! While I am discovering over in bug 1675916, that it is not easy to find the right spot where to ensure what ClientSource::MaybeCreateInitialDocument() currently wants to ensure (badly) - do we have a reduced testcase now? Or at least some testcase you could run against builds before the patch of bug 1544522 landed? I would want to understand, if we had the exact same root cause also before and it was just covered by the MOZ_DIAGNOSTIC_ASSERT somehow.

Flags: needinfo?(twsmith)

Tyson Smith [:tsmith]

Reporter

Comment 11

•

5 years ago

Here is what I see using with m-c 20201020-0139ef8538bf. The test case is reliable but fairly unreduced.

==176228==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000448f20 at pc 0x7f3f4fee9391 bp 0x7ffd056a1030 sp 0x7ffd056a1028
READ of size 8 at 0x60c000448f20 thread T0 (Web Content)
    #0 0x7f3f4fee9390 in IsCurrentThread src/xpcom/base/nsISupportsImpl.cpp:46:10
    #1 0x7f3f4fee9390 in nsAutoOwningThread::AssertCurrentThreadOwnsMe(char const*) const src/xpcom/base/nsISupportsImpl.cpp:39:7
    #2 0x7f3f55bb64d8 in AssertOwnership<29> /builds/worker/workspace/obj-build/dist/include/nsISupportsImpl.h:60:5
    #3 0x7f3f55bb64d8 in mozilla::dom::ClientSource::GetInnerWindow() const src/dom/clients/manager/ClientSource.cpp:195:3
    #4 0x7f3f55bb66c7 in mozilla::dom::ClientSource::MaybeCreateInitialDocument() src/dom/clients/manager/ClientSource.cpp:147:5
    #5 0x7f3f55bbbf7f in mozilla::dom::ClientSource::SnapshotState() src/dom/clients/manager/ClientSource.cpp:677:5
    #6 0x7f3f55bbe41a in mozilla::dom::ClientSource::GetInfoAndState(mozilla::dom::ClientGetInfoAndStateArgs const&) src/dom/clients/manager/ClientSource.cpp:662:44
    #7 0x7f3f55bc26c9 in void mozilla::dom::ClientSourceOpChild::DoSourceOp<RefPtr<mozilla::MozPromise<mozilla::dom::ClientOpResult, mozilla::CopyableErrorResult, false> > (mozilla::dom::ClientSource::*)(mozilla::dom::ClientGetInfoAndStateArgs const&), mozilla::dom::ClientGetInfoAndStateArgs>(RefPtr<mozilla::MozPromise<mozilla::dom::ClientOpResult, mozilla::CopyableErrorResult, false> > (mozilla::dom::ClientSource::*)(mozilla::dom::ClientGetInfoAndStateArgs const&), mozilla::dom::ClientGetInfoAndStateArgs const&) src/dom/clients/manager/ClientSourceOpChild.cpp:44:15
    #8 0x7f3f55bbfc20 in mozilla::dom::ClientSourceOpChild::Init(mozilla::dom::ClientOpConstructorArgs const&) src/dom/clients/manager/ClientSourceOpChild.cpp:97:7
    #9 0x7f3f55bbfb0e in mozilla::dom::ClientSourceChild::RecvPClientSourceOpConstructor(mozilla::dom::PClientSourceOpChild*, mozilla::dom::ClientOpConstructorArgs const&) src/dom/clients/manager/ClientSourceChild.cpp:43:10
    #10 0x7f3f515384dc in mozilla::dom::PClientSourceChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PClientSourceChild.cpp:365:28
    #11 0x7f3f5191a1eb in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PBackgroundChild.cpp:6231:32
    #12 0x7f3f5136d6ce in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) src/ipc/glue/MessageChannel.cpp:2150:25
    #13 0x7f3f51369684 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) src/ipc/glue/MessageChannel.cpp:2074:9
    #14 0x7f3f5136b488 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) src/ipc/glue/MessageChannel.cpp:1922:3
    #15 0x7f3f5136bf58 in mozilla::ipc::MessageChannel::MessageTask::Run() src/ipc/glue/MessageChannel.cpp:1953:13
    #16 0x7f3f50075cc9 in mozilla::RunnableTask::Run() src/xpcom/threads/TaskController.cpp:245:16
    #17 0x7f3f500727b7 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:515:26
    #18 0x7f3f50070657 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:374:15
    #19 0x7f3f50070aad in mozilla::TaskController::ProcessPendingMTTask(bool) src/xpcom/threads/TaskController.cpp:171:36
    #20 0x7f3f5007d591 in operator() src/xpcom/threads/TaskController.cpp:85:37
    #21 0x7f3f5007d591 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_3>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:577:5
    #22 0x7f3f5009d03b in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1197:14
    #23 0x7f3f500a78bc in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:513:10
    #24 0x7f3f5137636f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:87:21
    #25 0x7f3f51279831 in RunInternal src/ipc/chromium/src/base/message_loop.cc:334:10
    #26 0x7f3f51279831 in RunHandler src/ipc/chromium/src/base/message_loop.cc:327:3
    #27 0x7f3f51279831 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:309:3
    #28 0x7f3f5805ab97 in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:137:27
    #29 0x7f3f5bd7d3af in XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:913:20
    #30 0x7f3f51279831 in RunInternal src/ipc/chromium/src/base/message_loop.cc:334:10
    #31 0x7f3f51279831 in RunHandler src/ipc/chromium/src/base/message_loop.cc:327:3
    #32 0x7f3f51279831 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:309:3
    #33 0x7f3f5bd7c94c in XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:744:34
    #34 0x56052e183d2d in content_process_main(mozilla::Bootstrap*, int, char**) src/browser/app/../../ipc/contentproc/plugin-container.cpp:56:28
    #35 0x56052e184167 in main src/browser/app/nsBrowserApp.cpp:304:18
    #36 0x7f3f6c8e00b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16
    #37 0x56052e0d76c9 in _start (/home/user/workspace/browsers/m-c-20201020094032-fuzzing-asan-opt/firefox+0x5a6c9)

0x60c000448f20 is located 32 bytes inside of 128-byte region [0x60c000448f00,0x60c000448f80)
freed by thread T0 (Web Content) here:
    #0 0x56052e1512dd in free /builds/worker/fetches/llvm-project/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
    #1 0x7f3f535644d0 in operator delete /builds/worker/workspace/obj-build/dist/include/mozilla/cxxalloc.h:51:10
    #2 0x7f3f535644d0 in operator() /builds/worker/workspace/obj-build/dist/include/mozilla/UniquePtr.h:460:5
    #3 0x7f3f535644d0 in reset /builds/worker/workspace/obj-build/dist/include/mozilla/UniquePtr.h:302:7
    #4 0x7f3f535644d0 in nsGlobalWindowInner::EnsureClientSource() src/dom/base/nsGlobalWindowInner.cpp:1787:21
    #5 0x7f3f5356558d in nsGlobalWindowInner::ExecutionReady() src/dom/base/nsGlobalWindowInner.cpp:1881:17
    #6 0x7f3f535af8e4 in nsGlobalWindowOuter::SetNewDocument(mozilla::dom::Document*, nsISupports*, bool, mozilla::dom::WindowGlobalChild*) src/dom/base/nsGlobalWindowOuter.cpp:2423:26
    #7 0x7f3f5869b26f in nsDocumentViewer::InitInternal(nsIWidget*, nsISupports*, mozilla::dom::WindowGlobalChild*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, bool, bool, bool) src/layout/base/nsDocumentViewer.cpp:908:22
    #8 0x7f3f5869a70a in nsDocumentViewer::Init(nsIWidget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::dom::WindowGlobalChild*) src/layout/base/nsDocumentViewer.cpp:691:10
    #9 0x7f3f5b2e826f in nsDocShell::SetupNewViewer(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) src/docshell/base/nsDocShell.cpp:8148:7
    #10 0x7f3f5b2e7138 in nsDocShell::Embed(nsIContentViewer*, mozilla::dom::WindowGlobalChild*, bool) src/docshell/base/nsDocShell.cpp:5686:17
    #11 0x7f3f5b2f486e in nsDocShell::CreateAboutBlankContentViewer(nsIPrincipal*, nsIPrincipal*, nsIContentSecurityPolicy*, nsIURI*, mozilla::Maybe<nsILoadInfo::CrossOriginEmbedderPolicy> const&, bool, bool, mozilla::dom::WindowGlobalChild*) src/docshell/base/nsDocShell.cpp:6754:14
    #12 0x7f3f5b2b1f51 in nsDocShell::EnsureContentViewer() src/docshell/base/nsDocShell.cpp:6574:17
    #13 0x7f3f5b2ce8a7 in GetDocument src/docshell/base/nsDocShell.cpp:3178:3
    #14 0x7f3f5b2ce8a7 in non-virtual thunk to nsDocShell::GetDocument() src/docshell/base/nsDocShell.cpp
    #15 0x7f3f55bb66bf in mozilla::dom::ClientSource::MaybeCreateInitialDocument() src/dom/clients/manager/ClientSource.cpp:145:25
    #16 0x7f3f55bbbf7f in mozilla::dom::ClientSource::SnapshotState() src/dom/clients/manager/ClientSource.cpp:677:5
    #17 0x7f3f55bbe41a in mozilla::dom::ClientSource::GetInfoAndState(mozilla::dom::ClientGetInfoAndStateArgs const&) src/dom/clients/manager/ClientSource.cpp:662:44
    #18 0x7f3f55bc26c9 in void mozilla::dom::ClientSourceOpChild::DoSourceOp<RefPtr<mozilla::MozPromise<mozilla::dom::ClientOpResult, mozilla::CopyableErrorResult, false> > (mozilla::dom::ClientSource::*)(mozilla::dom::ClientGetInfoAndStateArgs const&), mozilla::dom::ClientGetInfoAndStateArgs>(RefPtr<mozilla::MozPromise<mozilla::dom::ClientOpResult, mozilla::CopyableErrorResult, false> > (mozilla::dom::ClientSource::*)(mozilla::dom::ClientGetInfoAndStateArgs const&), mozilla::dom::ClientGetInfoAndStateArgs const&) src/dom/clients/manager/ClientSourceOpChild.cpp:44:15
    #19 0x7f3f55bbfc20 in mozilla::dom::ClientSourceOpChild::Init(mozilla::dom::ClientOpConstructorArgs const&) src/dom/clients/manager/ClientSourceOpChild.cpp:97:7
    #20 0x7f3f55bbfb0e in mozilla::dom::ClientSourceChild::RecvPClientSourceOpConstructor(mozilla::dom::PClientSourceOpChild*, mozilla::dom::ClientOpConstructorArgs const&) src/dom/clients/manager/ClientSourceChild.cpp:43:10
    #21 0x7f3f515384dc in mozilla::dom::PClientSourceChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PClientSourceChild.cpp:365:28
    #22 0x7f3f5191a1eb in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PBackgroundChild.cpp:6231:32
    #23 0x7f3f5136d6ce in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) src/ipc/glue/MessageChannel.cpp:2150:25

previously allocated by thread T0 (Web Content) here:
    #0 0x56052e15155d in malloc /builds/worker/fetches/llvm-project/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x56052e195d0d in moz_xmalloc src/memory/mozalloc/mozalloc.cpp:52:15
    #2 0x7f3f55b793df in operator new /builds/worker/workspace/obj-build/dist/include/mozilla/cxxalloc.h:33:10
    #3 0x7f3f55b793df in mozilla::dom::ClientManager::CreateSourceInternal(mozilla::dom::ClientType, nsISerialEventTarget*, mozilla::ipc::PrincipalInfo const&) src/dom/clients/manager/ClientManager.cpp:122:34
    #4 0x7f3f55b7ae93 in mozilla::dom::ClientManager::CreateSource(mozilla::dom::ClientType, nsISerialEventTarget*, nsIPrincipal*) src/dom/clients/manager/ClientManager.cpp:266:15
    #5 0x7f3f5b2c63d6 in nsDocShell::MaybeCreateInitialClientSource(nsIPrincipal*) src/docshell/base/nsDocShell.cpp:2484:26
    #6 0x7f3f5b316da1 in nsDocShell::OpenInitializedChannel(nsIChannel*, nsIURILoader*, unsigned int) src/docshell/base/nsDocShell.cpp:10378:3
    #7 0x7f3f5b30ea0b in nsDocShell::DoURILoad(nsDocShellLoadState*, mozilla::Maybe<unsigned int>, nsIRequest**) src/docshell/base/nsDocShell.cpp:10254:10
    #8 0x7f3f5b267212 in nsDocShell::InternalLoad(nsDocShellLoadState*, mozilla::Maybe<unsigned int>) src/docshell/base/nsDocShell.cpp:9417:8
    #9 0x7f3f5b2b38d0 in nsDocShell::LoadURI(nsDocShellLoadState*, bool, bool) src/docshell/base/nsDocShell.cpp:875:8
    #10 0x7f3f53a3dc1d in nsFrameLoader::ReallyStartLoadingInternal() src/dom/base/nsFrameLoader.cpp:745:23
    #11 0x7f3f53a3d13e in nsFrameLoader::ReallyStartLoading() src/dom/base/nsFrameLoader.cpp:623:17
    #12 0x7f3f5378f685 in mozilla::dom::Document::MaybeInitializeFinalizeFrameLoaders() src/dom/base/Document.cpp:8650:13
    #13 0x7f3f538521ff in applyImpl<mozilla::dom::Document, void (mozilla::dom::Document::*)()> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1188:12
    #14 0x7f3f538521ff in apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1194:12
    #15 0x7f3f538521ff in mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1240:13
    #16 0x7f3f534cec23 in nsContentUtils::RemoveScriptBlocker() src/dom/base/nsContentUtils.cpp:5378:15
    #17 0x7f3f5377fe3f in mozilla::dom::Document::EndUpdate() src/dom/base/Document.cpp:7217:3
    #18 0x7f3f5343d396 in mozAutoDocUpdate::~mozAutoDocUpdate() src/dom/base/mozAutoDocUpdate.h:34:18
    #19 0x7f3f53a7f7ae in nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) src/dom/base/nsINode.cpp:2711:1
    #20 0x7f3f541d2c21 in InsertBefore src/dom/base/nsINode.h:1981:12
    #21 0x7f3f541d2c21 in AppendChild src/dom/base/nsINode.h:1988:12
    #22 0x7f3f541d2c21 in mozilla::dom::Node_Binding::appendChild(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) /builds/worker/workspace/obj-build/dom/bindings/NodeBinding.cpp:991:60
    #23 0x7f3f5555f878 in bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) src/dom/bindings/BindingUtils.cpp:3229:13
    #24 0x7f3f5bfe3b24 in CallJSNative src/js/src/vm/Interpreter.cpp:506:13
    #25 0x7f3f5bfe3b24 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) src/js/src/vm/Interpreter.cpp:598:12

Flags: needinfo?(twsmith)

Comment 12

•

5 years ago

Thanks! Interesting, so before bug 1544522 we failed UAF while evaluating the expression in the MOZ_DIAGNOSTIC_ASSERT (which is a call to the exact same function that fails later otherwise). So actually we do not see a regression from bug 1544522 here, that bug just slightly moved the failing spot.

Updated

•

5 years ago

Severity: -- → S2

Priority: -- → P1

Assignee

Updated

•

5 years ago

Assignee: jstutte → ytausky

Assignee

Comment 13

•

5 years ago

Based on the clues so far my assumption is that we have an iframe that begins its life unsandboxed, then while the initial about:blank is loaded becomes sandboxed. I'm trying to reproduce the error with this scenario, or some variation of it.

Assignee

Comment 14

•

5 years ago

Attached file Bug 1675097 - Trigger a UAF (obsolete) — Details

Assignee

Comment 15

•

5 years ago

I reproduced the UAF with the scenario described above. I also have a Pernosco session for it.

Updated

•

4 years ago

status-firefox83: affected → wontfix

status-firefox84: affected → wontfix

status-firefox85: --- → affected

status-firefox-esr78: --- → ?

Assignee

Comment 16

•

4 years ago

Attached file Bug 1675097 - Use the correct sandboxing flags for initial about:blank r=asuth,smaug — Details

Assignee

Comment 17

•

4 years ago

Attached file Bug 1675097 - Add regression test r=asuth,smaug — Details

Assignee

Comment 18

•

4 years ago

Comment on attachment 9192200 [details]
Bug 1675097 - Use the correct sandboxing flags for initial about:blank r=asuth,smaug

Security Approval Request

How easily could an exploit be constructed based on the patch?: The patch makes it obvious that the issue has something to do with an initial about:blank's sandboxing flags, but the UAF requires the use of the service workers clients interface, which is not referenced in the patch at all.
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
Which older supported branches are affected by this flaw?: All
If not all supported branches, which bug introduced the flaw?: None
Do you have backports for the affected branches?: No
If not, how different, hard to create, and risky will they be?: I would expect the patch to apply cleanly to ESR78, but I didn't check that yet.
How likely is this patch to cause regressions; how much testing does it need?: Very unlikely -- this patch changes the sandboxing flags used in a very specific situation.

Attachment #9192200 - Flags: sec-approval?

Tom Ritter [:tjr]

Comment 19

•

4 years ago

Comment on attachment 9192200 [details]
Bug 1675097 - Use the correct sandboxing flags for initial about:blank r=asuth,smaug

Approved to land and uplift. We can land the test in late March I think.

Attachment #9192200 - Flags: sec-approval?

Attachment #9192200 - Flags: sec-approval+

Attachment #9192200 - Flags: approval-mozilla-esr78+

Attachment #9192200 - Flags: approval-mozilla-beta+

https://hg.mozilla.org/integration/autoland/rev/242e995f5bf0d6f3446ee89381f1be3b651157be

Comment 20

•

4 years ago

status-firefox86: --- → affected

status-firefox-esr78: ? → affected

tracking-firefox85: --- → +

tracking-firefox86: --- → +

tracking-firefox-esr78: --- → 85+

Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)

Comment 21

•

4 years ago

https://hg.mozilla.org/mozilla-central/rev/242e995f5bf0

Group: dom-core-security → core-security-release

Status: NEW → RESOLVED

Closed: 4 years ago

status-firefox86: affected → fixed

Resolution: --- → FIXED

Target Milestone: --- → 86 Branch

Alexandru Michis [:malexandru]

Updated

•

4 years ago

Regressions: 1683792

BugBot [:suhaib / :marco/ :calixte]

Comment 22

•

4 years ago

Note on uplifts - we'll need to take the wpt manifest change in bug 1683792 as well.

Comment 23

•

4 years ago

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.

Flags: needinfo?(ytausky)

Whiteboard: [sec-survey]

Julien Cristau [:jcristau]

Assignee

Comment 24

•

4 years ago

I answered the survey.

Flags: needinfo?(ytausky)

Phabricator Automation

Updated

•

4 years ago

Attachment #9189137 - Attachment is obsolete: true

Comment 25

•

4 years ago

uplift

https://hg.mozilla.org/releases/mozilla-beta/rev/10661d8a4d55

status-firefox85: affected → fixed

Comment 26

•

4 years ago

This needs a rebased patch for ESR78. Note that the trivial rebase led to build failures on Try:
https://treeherder.mozilla.org/logviewer?job_id=325857725&repo=try&lineNumber=27150

Flags: needinfo?(ytausky)

Assignee

Comment 27

•

4 years ago

The patch depends on one of the patches in bug 444222, and both require slight modifications in order to apply correctly. Ryan, should I ask for an uplift on that bug, or can we do it here?

Flags: needinfo?(ytausky)

Comment 28

•

4 years ago

hrm, that's a good question. I saw some discussion in another recent bug related to bug 444222 which makes me wonder if we'll eventually need to consider uplifting that to ESR78. Andrew/Tom, any thoughts?

Flags: needinfo?(tom)

Flags: needinfo?(continuation)

Tom Ritter [:tjr]

Comment 29

•

4 years ago

•

Edited

Bug 444222 is pref-controlled and default-off in non-nightly, so I don't see a concern with uplifting it. We would probably not enable it on ESR though because it poses a webcompat concern....

Flags: needinfo?(tom)

Comment 30

•

4 years ago

I don't know anything about Bug 444222, sorry.

Flags: needinfo?(continuation)

Assignee

Comment 31

•

4 years ago

Attached file Bug 1675097 - Use the correct sandboxing flags for initial about:blank r=asuth,smaug — Details

Assignee

Comment 32

•

4 years ago

The new patch incorporates this patch from bug 444222 since it's very small.