1881037 - (CVE-2024-9398) Leaking Browser URL/Protocol Handlers through window.open() behavior

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Satoki Tsuji]

Attachment: PoC.html

I am aware that a highly skilled hacker previously identified a vulnerability related to leaking URL/Protocol Handlers through an img tag in CVE-2020-15680. I consulted the following article for my research:
https://www.fortinet.com/blog/threat-research/leaking-browser-url-protocol-handlers

The technique discussed in this article involves using the size of an img tag as a means to leak information. However, I have discovered a simpler method of leaking such information in the latest version of Windows Desktop Firefox (122.0.1 64bit).

I have found a method that can determine whether a URI scheme is valid based on the behavior of accessing the return value of window.open (whether it is undefined or throws an error). Here is an example:

site1 = window.open("satoki://satoki");
site1[0]; // Error
site2 = window.open("steam://satoki"); // e.g., Steam Client installed
site2[0]; // undefined

This method exploits the difference in behavior when accessing the return value of window.open for a custom URI scheme, allowing one to infer the presence or absence of the corresponding protocol handler. If an error is thrown, it indicates the scheme is not recognized; if the result is undefined, it suggests the scheme is recognized but the resource is not accessible or does not exist.

Once we've reached this point, all that's left is to send a request externally with JavaScript, just like in the case of CVE-2020-15680 (using an img tag, for instance, if fetch is prohibited). I will attach a PoC (Proof of Concept) file. This employs the same mechanism as the example of CVE-2020-15680.

Comment 1

[Satoki Tsuji]

Attachment: request leak

I'm using requestbin as a stand-in for the attacker's server, so I'll also attach the response from it. The URI schemes for which no request has been received are considered to be installed.

Comment 2

[Satoki Tsuji]

Attachment: eg.png

A simple difference in behavior can be seen in the browser console.

Comment 3

[Daniel Veditz [:dveditz]]

Will have to try on a windows machine, but on Mac this PoC didn't work. The testcase made a fetch for all 8 handlers and I obviously don't have the windows-specific protocols installed (I do have a couple of the others). And of course to run this test you have to allow popups, or else you would only be able to test one scheme per click you could get the user to do.

Did you run this test from an http server, or from a local file? Permissions to open external handlers from local files are handled slightly differently than from an actual domain, where there's a prompt to allow that scheme. In practice I think you could only learn about schemes that users used from the site you were able to inject your attack. That's quite different from the situation in bug 1658881 four years ago.

Comment 4

[Satoki Tsuji]

Of course, I tried it on remote servers as well.
Permission to open the popup is needed only once (this "open://satoki" is intended to obtain permission).
However, if you open subsequent popups with a delay, this PoC (Proof of Concept) works.

This vulnerability requires the injection of JavaScript, which should be the same for bug 1658881.
That means the victim must access a page created by the attacker.
Like bug 1658881, it allows for Identifying communication channels, General reconnaissance, Pre-exploitation detection, Detecting Security solutions, and User Fingerprinting.
In other words, it can be seen as a new method of XS-leaks to verify whether the schema is effective or not.
I recognize that leaking tools installed by the user should be avoided.

I will show you the video I tested.

Comment 5

[Satoki Tsuji]

Attachment: PoC.mkv

Attached PoC video :)

Comment 6

[Satoki Tsuji]

Attachment: new_10s_PoC.html

Comment 7

[Andreas Farre [:farre]]

I could reproduce this as well, on Fedora Linux with Steam installed. It required allowing popups, so maybe slightly less severe, but I'll set it to S3, same as bug 1658881, and bring it to the DOM Core meeting.

Comment 8

[Daniel Veditz [:dveditz]]

Lowering the severity because an attack would have to gather this data slowly and convince the user to click on enough things to work (in practice; asking someone to disable the popup blocker so you can spam them isn't very stealthy).

There might be some underlying cause with bug 1882364, such as maybe when we canonicalize URLs we consider unknown schemes differently from ones we know the OS has support for and return a different error earlier in the process (we might check that later though).

Comment 9

[Satoki Tsuji]

thx. I also agree with rating it as low. This attack vector can only be used on sites where the user has allowed pop-ups. Although it may have a different cause than bug 1882364, the countermeasure could possibly be applied commonly at the initial stage of URI loading.

Comment 10

[Daniel Veditz [:dveditz]]

(In reply to Satoki Tsuji from comment #4)

This vulnerability requires the injection of JavaScript, which should be the same for bug 1658881.
That means the victim must access a page created by the attacker.

We assume users will browse hostile pages, whether through SEO'd search results, clickbait titles, hacked sites, malicious ads, or whatever. Or in the case of this kind of bug, a "legitimate" site that wants to fingerprint you to make money with ads.

it can be seen as a new method of XS-leaks

jargon nitpick: this issue is not what we mean by "cross-site leaks". The attacker learns things about the user, but not about the private content of other sites.

Comment 11

[Daniel Veditz [:dveditz]]

This technique might not be stopped by the changes Nika proposed in bug 1883693, because we'll still return NS_ERROR_UNKNOWN_PROTOCOL in the end. For an unknown protocol handler the popup contains the network error page. Attempts to access properties on that window results in a same-origin access violation. In the case of an existing handler the popup remains the original about:blank window because the content is loaded outside Firefox. Attempts to access the same-origin about:blank window are not a problem. site2[0] is undefined because a window isn't an array, but other properties can be accessed like site2.location or site2.document.

We should probably turn that into a non-error error page ("Your content has been loaded in another application" ?) so that the effects are consistent.

There's a bit of timing involved as well: The error case happens immediately, but for an existing handler we often will prompt the user to ask if they want to open it. If we wait until the user says "yes" to show the "non-error page" then the attack page has plenty of time to detect the about:blank. But if we show text right away it has to be generic enough to work whether the user says yes or no to the prompt.

If the user has previously granted permanent ability to launch that kind of handler (e.g. mailto:) we'll get slightly different timing, and we also need to worry about the case where the user has specifically blocked that handler even though it does exist on the OS. That case might behave the same as if it didn't exist, and if so that makes it easier—but it might need special handling. I don't know if we have current UI that can get a user into this state, but we do have prefs that can be manually set.

Comment 12

[Daniel Veditz [:dveditz]]

One quick hack might be to replace about:blank with something like "data:text/plain,". The null principal will be cross-origin to the attacker's page, but it will still look blank so we don't have to argue about the text and then wait for translations before we can ship it.

Comment 13

[Daniel Veditz [:dveditz]]

Anything like the "quick hack" would have to be limited to the cases where we do show that error content to avoid annoying people by replacing their open page. See https://searchfox.org/mozilla-central/rev/6b0b8c1003504e302e243c300355ef4d61e24909/docshell/base/nsDocShell.cpp#6199-6216

Looking at that code, setting dom.no_unknown_protocol_error.enabled to false should suppress the error page. That could be another way to make the cases indistinguishable, but it doesn't seem to help for this bug: I still get the error page in the popup. Is it broken? or does that filtering only apply to other cases?

Comment 14

[Satoki Tsuji]

Attachment: PoC.html

Comment 15

[Satoki Tsuji]

add window.history.length technique

Comment 16

[Satoki Tsuji]

Bug1882364 has been resolved, but is there any progress on this one?

Comment 17

[:Gijs (he/him)]

Nika or Farre, looks like the changes in bug 1883693 did not address this - do you have cycles to take a look at what's different / what would need to happen here? (Feel free to redirect!)

Comment 18

[Nika Layzell [:nika] (ooo, ni? for response)]

My guess is that this is a quite different situation. When loading a document, if the protocol exists, we'll have a successful load which will end with starting the external application, meaning that the document will stay on a same-origin about:blank document and/or will be close()-ed due to being the first load in the new window. In contrast, a failed load will display a load error page, which will be cross-origin from the original window and not closed.

This error page is shown due to the check which was noted in comment 11 (https://searchfox.org/mozilla-central/rev/7f7ea528f740dfbfd871c28362070982ef5f01e9/docshell/base/nsDocShell.cpp#6157-6173). We suppress the error page for non-system-triggered navigations unless the navigating BrowsingContext currently contains an initial about:blank document since bug 1528305. It seems that Chrome's behaviour is to never display an error page in this situation as well, which avoids this situation.

I'm unsure what case was specifically intended to be handled by showing the error page for non-system-principal initial loads, but perhaps we could limit it further by also checking something like !IsTop() || IsTopLevelCreatedByWebContent() (https://searchfox.org/mozilla-central/rev/7f7ea528f740dfbfd871c28362070982ef5f01e9/docshell/base/BrowsingContext.h#138-141), and suppressing the error page navigation in that case, as we probably don't want to show the error page for iframes or pop-up windows.

:emilio I don't suppose you remember the specifics of why these conditions were chosen for that check?

Comment 19

[Emilio Cobos Álvarez (:emilio)]

The idea was to prevent the error page triggered by content from replacing useful stuff.

I think I tested something like window.open() and at the time I didn't change the behavior, probably because it seemed a more useful error than a blank window, and was preserving behavior and thus a bit less risky...

It seems removing the initial document check might be enough here?

Comment 20

[Satoki Tsuji]

Hello,
It's about time I need to publish a WriteUp article on this issue. Do you have any updates?
If this poses a security risk, I will stop the publication (I will never disclose a 0day vulnerability).

Comment 21

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Sorry for the delay here. Nika said she could write a patch for it, though testing might not really be easy.

Comment 22

[Nika Layzell [:nika] (ooo, ni? for response)]

Attachment: Bug 1881037 - Part 1: Stop showing unknown protocol error pages for web-triggered loads, r=smaug!

Comment 23

[Nika Layzell [:nika] (ooo, ni? for response)]

Attachment: Bug 1881037 - Part 2: Add a basic test for loading unknown protocols in a popup window, r=smaug!

The console notification is only created when an error page would not
otherwise load, so allows us to detect the situation where the error
page is not going to be loaded.

Depends on D217495

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/db0212e2c079
Part 1: Stop showing unknown protocol error pages for web-triggered loads, r=smaug,necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/30866fb1a697
Part 2: Add a basic test for loading unknown protocols in a popup window, r=smaug
https://hg.mozilla.org/integration/autoland/rev/c948d8669436
apply code formatting via Lando

Comment 25

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

Backed out for causing mochitest failure in test_popup_unknown_protocol.html :
https://hg.mozilla.org/integration/autoland/rev/3ad5ff66974211b81c77b57cbaa979f1503ad563

Push with failures
Failure log

[task 2024-08-09T21:18:25.110Z] 21:18:25     INFO -  TEST-START | docshell/test/mochitest/test_popup_unknown_protocol.html
[task 2024-08-09T21:23:27.670Z] 21:23:27     INFO -  Buffered messages logged at 21:18:21
[task 2024-08-09T21:23:27.670Z] 21:23:27     INFO -  add_task | Entering
[task 2024-08-09T21:23:27.670Z] 21:23:27     INFO -  Opened pop-up
[task 2024-08-09T21:23:27.671Z] 21:23:27     INFO -  Buffered messages logged at 21:18:22
[task 2024-08-09T21:23:27.671Z] 21:23:27     INFO -  waiting for console message error
[task 2024-08-09T21:23:27.671Z] 21:23:27     INFO -  Got console message: Storage access automatically granted for origin “moz-nullprincipal:{a2e30023-58ce-47e2-995b-c5e1cf0dde7a}” on “http://mochi.test:8888”.
[task 2024-08-09T21:23:27.671Z] 21:23:27     INFO -  Buffered messages finished
[task 2024-08-09T21:23:27.671Z] 21:23:27  WARNING -  TEST-UNEXPECTED-FAIL | docshell/test/mochitest/test_popup_unknown_protocol.html | Test timed out. -

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

(I don't even know why the bot added needinfo)

Comment 27

[Nika Layzell [:nika] (ooo, ni? for response)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #26)

(I don't even know why the bot added needinfo)

(I think it's because you were the reviewer)

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/975331bc9956
Part 1: Stop showing unknown protocol error pages for web-triggered loads, r=smaug,necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/53a74573c786
Part 2: Add a basic test for loading unknown protocols in a popup window, r=smaug
https://hg.mozilla.org/integration/autoland/rev/946426bcca27
apply code formatting via Lando

Comment 29

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

https://hg.mozilla.org/mozilla-central/rev/975331bc9956
https://hg.mozilla.org/mozilla-central/rev/53a74573c786
https://hg.mozilla.org/mozilla-central/rev/946426bcca27

Comment 30

[Satoki Tsuji]

Why is this out of scope for the Bug Bounty program? It behaves the same as CVE-2024-5690 and seems to be a security issue. Also, is there a possibility that these issues will be assigned a CVE?

Comment 31

[Andrew McCreight (out of office until 8/21) [:mccr8]]

(In reply to Satoki Tsuji from comment #30)

Why is this out of scope for the Bug Bounty program? It behaves the same as CVE-2024-5690 and seems to be a security issue. Also, is there a possibility that these issues will be assigned a CVE?

Questions about our bug bounty program are more likely to get answered if you email them to [e-mail]

Comment 32

[Satoki Tsuji]

Hello,

I received an email stating that the reason I wasn't awarded a CVE for this bug is due to the following:

Hi,

Thank you for discovering and reporting the leak in https://bugzilla.mozilla.org/show_bug.cgi?id=1881037. Exploiting the bug achieves a similar capability like https://bugzilla.mozilla.org/show_bug.cgi?id=CVE-2024-5690, that is true.

However, we see a difference in exploitation: The data can only be gathered very slowly, and the attacker needs to convince the user to click on a link. The attack that we have seen is also very visible, making efficient exploitation really unlikely. Attacks with other web APIs that can be hidden from the user are just more severe to us.

Let me know if there are any other questions, but note that this is not a negotiation. Great job on the other bugs, so just keep looking :)

Thanks,
Freddy

In response to the concerns mentioned, I have written a PoC that resolves the issues related to the slow data extraction speed and the need for a user prompt through a technical insight. This PoC now fully achieves the same outcome as CVE-2024-5690. I believe this clearly demonstrates that the vulnerability still exists.

Comment 33

[Satoki Tsuji]

Attachment: PoC.html

Comment 34

[Satoki Tsuji]

I would like to emphasize that this issue has already been resolved in the latest Firefox Nightly. Specifically, I have confirmed that the fix in version 131 addresses this. What I want to stress is that this is not just a bug, but a vulnerability.

Comment 35

[Frederik Braun [:freddy] (OOO until August 18th)]

To clarify, the email is pointing out that we made the decision not to award a bounty.
Fixed security bugs will still get a CVE assigned when it comes to release (I wouldn't call it "awarded". CVEs are not an award).

Anyhow, we will take a look at the PoC and revisit in our next bounty meeting. Thank you for taking a further look here.

Comment 36

[Frederik Braun [:freddy] (OOO until August 18th)]

Satoki, I think we need some more information. I appreciate you getting back to us and providing a new variant of the PoC.
However, when trying with an unfixed version (Firefox 129.0.2), I can not reproduce your issue.

The PoC claims that all protocol handlers except "satoki://" exist, whereas almost none of the protocol handlers should actually exist.

Full results copied from PoC for my system (macOS):

Result

Handler satoki:// Does not exist
Handler amazon:// Exists
Handler ftp:// Exists
Handler geo:// Exists
Handler instagram:// Exists
Handler mailto:// Exists
Handler ms-edge:// Exists
Handler ms-store:// Exists
Handler onenote:// Exists
Handler skype:// Exists
Handler slack:// Exists
Handler sms:// Exists
Handler spotify:// Exists
Handler steam:// Exists
Handler tel:// Exists
Handler twitch:// Exists
Handler twitter:// Exists
Handler whatsapp:// Exists
Handler zoommtg:// Exists

Comment 37

[Satoki Tsuji]

hi
Try increasing the threshold variable in JavaScriot, now it works with a very small value. Attach a video if necessary.

Comment 38

[Satoki Tsuji]

Attachment: PoC_new.html

Comment 39

[Satoki Tsuji]

I would like to introduce the techniques used this time. Previously, I exploited an access error to the object returned by window.open. This technique took advantage of a basic browser function designed to prevent cross-origin access. However, it required opening a popup (i.e., a new page). To avoid detection by the user, this time I used an iframe and exploited an access violation error to iframe.contentWindow.history.length. Although a scheme permission popup (not the page opening kind) can appear with iframes, I suppressed it by setting iframe.sandbox = "". The iframe is created using JavaScript, and it is necessary to wait a few milliseconds until the page loads. This waiting time is the threshold.

Comment 40

[Frederik Braun [:freddy] (OOO until August 18th)]

With PoC_new.html I get Exists for every protocol, including satoki. This can't be right. Maybe someone else should try and reproduce?. Apologies I tested in Firefox Nightly.

When testing in Firefox release on macOS (129.0.2), I get the same results. "Exists" for everything and "Does not exist" for Satoki. But I do not have any handlers installed for most of the protocols listed there.

I think someone else should try to reproduce.

Comment 41

[Valentin Gosu [:valentin] (he/him)]

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

With PoC_new.html I get Exists for every protocol, including satoki. This can't be right. Maybe someone else should try and reproduce?. Apologies I tested in Firefox Nightly.

When testing in Firefox release on macOS (129.0.2), I get the same results. "Exists" for everything and "Does not exist" for Satoki. But I do not have any handlers installed for most of the protocols listed there.

I see the same in 129 on Ubuntu Linux.
And exists for everything in 131.
Same thing happens if I increase or decrease the threshold value.

Comment 42

[Satoki Tsuji]

Attachment: PoC_videos.mp4

Comment 43

[Satoki Tsuji]

I sent you the latest firefox PoC video. Maybe it needs a little adjustment depending on your environment. can you try using PoC_new.html?

Comment 44

[Satoki Tsuji]

You may be caught in the limitation of continuous iframe generation. Fix the PoC, which can certainly be accomplished without using window.open. Integrate to do it in one iframe.

Comment 45

[:Gijs (he/him)]

I also can't reproduce immediately on Windows with 129.

Your video shows that you're trying in a Firefox profile that has a number of add-ons installed and perhaps other settings changed. It would be useful if you could try in a clean profile.

I have tried to play around with the testcase a bit. I note the following:

1. if you change the order of the known_protocol_handlers, the first item is always "does not exist", whereas all the other items log "exists". So that suggests that something is throwing an error the first time the checkHandlersExistence code checks a protocol in the loop, but it's not clear what.
2. I'm a bit confused about the ordering of operations - you're adding the iframe to the DOM and then changing its sandbox property. If I change the order (ie set sandbox = "" and then append) then every item in the list logs "does not exist" instead.
3. I tried to make the test run sequentially so the individual loads didn't interfere with each other in any way, and logged errors from the catch block. I see a number of:

Iframe with external protocol was blocked due to lack of user activation, or because not enough time has passed since the last such iframe was loaded.

as well as:

Blocked navigation to custom protocol “mailto://satoki” from a sandboxed context.

and

DOMException: Permission denied to access property "history" on cross-origin object

I looked up the code for the "due to lack of user activation" error, which is https://searchfox.org/mozilla-central/rev/45d6f8bf028e049f812aa26dced565d50068af5d/docshell/base/nsDocShell.cpp#10125-10137 . That code only runs if we block popups. I deduce that you probably previously allowed popups for this domain - but the testcase doesn't work if you don't first allow popups.

If I manually run a window.open call from the console in the test page, and then allow all popups for the domain from the UI, then reload the testcase, I can reproduce the testcase producing meaningful-looking results (on 129).

Comment 46

[Satoki Tsuji]

Attachment: PoC_display.html

Comment 47

[Satoki Tsuji]

I am presenting a version with display set to on. By observing the changes within this iframe, the PoC becomes clearer. Currently, I am resolving the message 'The iframe with an external protocol has been blocked because the user has not granted permission or sufficient time has not passed since the iframe was last loaded.' (This is why it takes 10 seconds). The main technique here is whether the content inside the iframe becomes about:blank or results in an error. This aspect is the same as using window.open(). However, if a scheme exists, a confirmation dialog for handling it will appear, which is disabled using the sandbox attribute. To prevent interference from add-ons, I am conducting the validation using a newly installed Firefox within Windows Sandbox.

Comment 48

[Satoki Tsuji]

The message 'Iframe with external protocol was blocked due to lack of user activation, or because not enough time has passed since the last such iframe was loaded.' is very troublesome and is the cause this time. When blocked, the state of the previous page is reflected in the state of the next scheme, meaning that 'Exist' is repeated. This requires a 10-second interval. If the interval is applied, the scheme can be leaked.

The message 'Blocked navigation to custom protocol "mailto://satoki" from a sandboxed context.' is unrelated. It suppresses pop-ups such as 'Open in mail.' When a pop-up occurs, it becomes visible to the user.

The message 'DOMException: Permission denied to access property "history" on cross-origin object' indicates success. This shows that access to the page's history (iframe.contentWindow.history.length) is denied, indicating that the scheme does not exist.

Comment 49

[Satoki Tsuji]

Sorry for my broken English, especially since I’m currently on a business trip abroad and my English is even more disorganized. I’m sending you the simplest PoC.

let iframe = document.createElement("iframe");
document.body.appendChild(iframe);
iframe.sandbox = "";
iframe.src = "steam://satoki";
// sleep 500ms
iframe.contentWindow.history.length; //OK! -> Exists
// sleep 10s
iframe.src = "omgomg://satoki";
// sleep 500ms
iframe.contentWindow.history.length; //ERROR -> Does not exist

This is how to do the same thing with an iframe as with window.open.

Comment 50

[Frederik Braun [:freddy] (OOO until August 18th)]

OK, this is interesting. I modified the test case to use two different protocols based on what I have installed locally (first spotify, then steam. This machine has steam but not spotify.). In both cases, I received DOMException: Permission denied to access property "history" on cross-origin object when trying to access iframe.contentWindow.history.length; on the iframe.

However, if I change the order of the checks and start with steam (installed) and then go over to spotify (not present), I do get a different error. The first case (steam) complains that a navigation to a custom protocol (steam) was disabled from a sandboxed content, however history.length is accessible as 4.

Maybe the test needs to create new iframes for robust testing?

Comment 51

[Satoki Tsuji]

The reason it worked when the order was changed is that the sleep command became unnecessary. If you manually execute each line and strictly adhere to the sleep commands as mentioned in the comments, the order doesn't matter.

In the end, user interaction is no longer required, and the dialog for opening the app does not appear. In other words, it becomes completely stealthy from the user's perspective. However, due to my lack of technical skill, I currently cannot open iframes continuously at a speed faster than 10 seconds (except in special environments). As a result, it leads to a slow scheme leak. Nevertheless, it is still practical for extracting specific schemes.

Comment 52

[Satoki Tsuji]

Attachment: PoC_10s.html

Comment 53

[Dianna Smith [:diannaS]]

:nika do you still plan on nominating this for esr128? (if so, just a friendly reminder that RC week is next week)

Comment 54

[Nika Layzell [:nika] (ooo, ni? for response)]

Comment on attachment 9418632 [details]
Bug 1881037 - Part 2: Add a basic test for loading unknown protocols in a popup window, r=smaug!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Potential leak of external protocol information which could be used by e.g. fingerprinting
• User impact if declined: Potential leak of external protocol information which could be used by e.g. fingerprinting
• Fix Landed on Version: 131
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Fairly straightforward change to suppress error page in an edge-case for web-controlled content.

Comment 55

[Nika Layzell [:nika] (ooo, ni? for response)]

Sorry thought I had already requested uplift for some reason.

Comment 56

[Nika Layzell [:nika] (ooo, ni? for response)]

Comment on attachment 9414470 [details]
Bug 1881037 - Part 1: Stop showing unknown protocol error pages for web-triggered loads, r=smaug!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: see above
• User impact if declined: see above
• Fix Landed on Version: 131
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): see above

Comment 57

[Dianna Smith [:diannaS]]

Comment on attachment 9414470 [details]
Bug 1881037 - Part 1: Stop showing unknown protocol error pages for web-triggered loads, r=smaug!

Approved for 128.3esr

Comment 58

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/9f3bfadcf8ff
https://hg.mozilla.org/releases/mozilla-esr128/rev/4c3351b49449

Comment 59

[:Gijs (he/him)]

This was reopened, but AIUI there is no disagreement this is in fact fixed (per comment 34), the disagreement is about the severity of the issue that was fixed (comment 32). So I'm going to close this out again to avoid confusion about the state of this bug.

Comment 60

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt