1746844 - Don't crash when force-browsing about:httpsonlyerror and clicking "continue to site"

Status: RESOLVED INVALID

(Core :: DOM: Security, defect, P3)

Description

[Frederik Braun [:freddy]]

STR:

1. Navigate to about:httpsonlyerror?e=netTimeout&u=https%3A//example.com/browser/dom/security/test/https-only/file_iframe_test.sjs%3Ftest2.1&c=UTF-8&d=The%20server%20at%20example.com%20is%20taking%20too%20long%20to%20respond.
2. There's an error page
3. Click "Continue to site"

Actual result:
The child process crashes, but address sanitizer does not write a crash report. Console output is

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:364:7 in XRE_InitChildProcess(int, char**, XREChildData const*)
==21937==ABORTING
IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PWindowGlobal::Msg_ReloadWithHttpsOnlyException Processing error: message was deserialized, but the handler returned false (indicating failure)


###!!! [Parent][MessageChannel] Error: (msgtype=0x230081,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x2300A2,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

Expected result:
The browser goes to example.com or Nothing happens.

Comment 1

[Frederik Braun [:freddy]]

I used a non-asan nightly and managed to get this crash report submitted though:
https://crash-stats.mozilla.org/report/index/5b9422b5-637c-4860-b4df-2a3850211220

(NB: Address sanitizer did not manage to create a crash report, so maybe this is interesting for decoder?)

Comment 2

[Christian Holler (:decoder)]

(In reply to Frederik Braun [:freddy] from comment #1)

I used a non-asan nightly and managed to get this crash report submitted though:
https://crash-stats.mozilla.org/report/index/5b9422b5-637c-4860-b4df-2a3850211220

(NB: Address sanitizer did not manage to create a crash report, so maybe this is interesting for decoder?)

This is not a crash. The report has DUMP_REQUESTED in it, so this is probably some type of requested dump for diagnostic purposes?

Comment 3

[Frederik Braun [:freddy]]

Right this is one of the MOZ_CRASHes from IPCError.

Comment 4

[Daniel Veditz [:dveditz]]

What's different about your URL and what happens when I hit an non-HTTP site in Httpsonly mode? I've never seen this crash when I "continue" in normal browsing, but I can certainly crash with your URL.

Comment 5

[Daniel Veditz [:dveditz]]

Is this even sec-low? We are crashing ourselves to prevent a problem. Users will not be able to write a page containing a link like this to cause other people to crash, but depending on the answer to the previous question maybe they can cause it by sending folks to a site that triggers the right error condition?

Comment 6

[Frederik Braun [:freddy]]

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

Is this even sec-low?

Probably not. It's like about:crashcontent, but unintentional ;)

Comment 7

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

The severity field is not set for this bug.
:ckerschb, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Frederik Braun [:freddy]]

IPC_FAIL looks like the desired outcome after all.

https://searchfox.org/mozilla-central/rev/670e2e0999f04dc7734c8c12b2c3d420a1e31f12/dom/ipc/WindowGlobalParent.cpp#1290-1292