1705211 - (CVE-2022-22748) Security: Origin spoof in external protocol dialogs via server-side redirect to external protocol

Status: VERIFIED FIXED

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

Description

[Alesandro Ortiz]

Attachment: spoofs-calc.mp4

VULNERABILITY DETAILS
A URL responding with a server-side redirect to an external protocol can trigger an external protocol dialog with a spoofed origin. The origin is never the redirecting URL's origin. Instead, the initiating page's origin (or precursor origin if opaque) is shown in dialogs.

For example, if a page on https://www.google[.]com contains a link (<a href="...">) to https://attacker[.]tld/redirect, and a user clicks the link, the dialog will show https://www.google[.]com as the origin instead of https://attacker[.]tld .

Similarly, if a page on https://www.google[.]com navigates the current window or new window via JavaScript (window.location or window.open()) to https://attacker[.]tld/redirect, the dialog will show https://www.google[.]com as the origin.

In effect, the behavior is the same as if the page had directly used the external protocol URL (ms-calculator:) instead of the HTTPS URL (https://attacker[.]tld/redirect).

As far as I can tell, common protections such as CSP and iframe sandboxing are bypassed in most scenarios.

No user interaction is needed if a user previously checked "Always allow {origin} to open {protocol} links" and "Always use this application to open {protocol} links" for the target origin and protocol, or if allowed via enterprise policy: https://github.com/mozilla/policy-templates/blob/master/README.md#handlers

ADDITIONAL INFO
A malicious URL could be placed in search result pages, "external link" interstitial pages, user-provided URLs in content, among many other scenarios. Most websites filter input to only allow http(s) URLs (generally to avoid javascript: URLs which are blocked by browser in server-side redirects), therefore this works as an effective bypass to spoof the origin across most websites and navigation methods.

See attached video spoof-google-search.mp4 for Google Search demo with both calc and tel PoCs. Note that I only enabled this PoC to work from my IP address for a few minutes to record the video.

External protocols in server-side redirects probably should be treated similarly to javascript: URLs in server-side redirects, which are blocked by the browser as unsafe. Otherwise, the browser could render a blank page with origin set to the server-side redirect initiator, to ensure the dialog and address bar show the correct origin and the tab doesn't have another origin's content rendered.

VERSION
Firefox Version: 87.0 Stable (Build ID 20210318103112), also repros in 89.0a1 Nightly (Build ID 20210413093459 and 20210414093129)
Operating System: Windows_NT 10.0 19042

REPRODUCTION CASE
Scenario 1: Link click

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-links.html
2. Click either of the links

Observed: External protocol dialog shown with current page origin (https://alesandroortiz[.]com)
Expected: External protocol dialog is not shown or is shown with redirecting origin (https://aogarantiza[.]com)

Scenario 2: JavaScript redirect (window.location)

1. Navigate to https://www.google.com/url?q=https%3A%2F%2Faogarantiza.com%2Ffirefox%2Fexternal-protocol%2Fcalc.php&sa=D&sntz=1&usg=AFQjCNEoF7jt2NHEpoTRgtZbbx8F6Na1Gg

Observed: Dialog shown with spoofed origin.
Expected: Dialog shown with correct origin.

Scenario 3: Page has iframe with user-controlled src to URL responding with server-side redirect

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-sandbox-calc.html

Observed: Dialog shown with embedding page origin (https://alesandroortiz[.]com)
Expected: Dialog shown with iframe src origin (https://aogarantiza[.]com)

Scenario 4: Attacker page with refreshing iframe with client-side redirect leading to server-side redirect

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-src-calc.html

Observed: Dialog repeatedly shown with embedding page origin (https://alesandroortiz[.]com)
Expected: Dialog repeatedly shown with iframe src origin (https://aogarantiza[.]com)

Scenario 5: Background tab is able to show dialog on different tab, combined with refreshing iframe for repeated dialogs (the latter also demonstrated in Scenario 4 PoC)

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-calc-diff-tab.html
2. Click "Continue to Google.com" button

Observed: Dialog is shown in the currently active tab, even if the tab is on a different origin
Expected: Dialog is only shown in tab which opened the dialog and was opened by the same origin as the current page

Scenario 6: Non-security UI bug -- Page with iframe srcdoc (sandboxed)

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-srcdoc-calc.html
2. Observe onload PoC of second iframe, then click link in first iframe

Observed: Dialog shown with checkbox, but checkbox label is blank. Checking the box doesn't do anything, but in this case the checkbox should be hidden. For reference, the origin shown is moz-nullprincipal: which is expected behvior.
Expected: Dialog shown without checkbox.

Other scenarios in PoCs below.

You can re-test any of the app protocol PoCs after checking "Always allow..." and "Always use..." to verify the app will be launched without interaction if previously allowed.

ALL PROOF OF CONCEPTS
App protocols:
https://alesandroortiz.com/security/firefox/external-protocol/spoof-links.html
https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-sandbox-calc.html
https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-src-calc.html
https://alesandroortiz.com/security/firefox/external-protocol/spoof-calc-diff-tab.html

App protocols, misc:
https://alesandroortiz.com/security/firefox/external-protocol/spoof-new-tab.html

Non-security UI bug with sandbox + srcdoc behavior:
https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-srcdoc-calc.html

Google external link demo, user click (equivalent to spoof-links.html PoC):
https://www.google.com/url?q=https://aogarantiza.com/firefox/external-protocol/calc.php

Google ~open client-side redirect demo, window.location (used in iframe PoCs to spoof Google origin):
https://www.google.com/url?q=https%3A%2F%2Faogarantiza.com%2Ffirefox%2Fexternal-protocol%2Fcalc.php&sa=D&sntz=1&usg=AFQjCNEoF7jt2NHEpoTRgtZbbx8F6Na1Gg

The automatic Google redirect links were created by creating links in Google Sites: https://sites.google.com/view/aortest1/external-protocol-poc-1-firefox

Source for HTML files attached. Source for server-side redirect URLs below:
calc.php: <?php header('Location: ms-calculator:'); ?>

CREDIT INFORMATION
Reporter credit: Alesandro Ortiz https://AlesandroOrtiz.com

Comment 1

[Alesandro Ortiz]

Attachment: spoofs-google.mp4

Comment 2

[Alesandro Ortiz]

Attachment: spoof-google-search.mp4

Comment 3

[Alesandro Ortiz]

Attachment: spoof-links.html

Comment 4

[Alesandro Ortiz]

Attachment: spoof-iframe-sandbox-calc.html

Comment 5

[Alesandro Ortiz]

Attachment: spoof-iframe-src-calc.html

Comment 6

[Alesandro Ortiz]

Attachment: spoof-iframe-srcdoc-calc.html

Comment 7

[Alesandro Ortiz]

Attachment: spoof-calc-diff-tab.html

Comment 8

[Alesandro Ortiz]

Attachment: spoof-new-tab.html

Comment 9

[Daniel Veditz [:dveditz]]

There's probably no way to win -- did the 3rd party resource maliciously redirect to the protocol (and it should be blamed) or did the framing site pick that link because they knew it redirected (especially with an "open redirect" on some site)?

Probably should just ban external protocol links from redirects, http/https redirects should only go to other http/https links.

Comment 10

[Alesandro Ortiz]

Be advised this behavior also repros in other browsers, and I've filed reports with them. Coordination may be needed if disclosure dates are misaligned.

Comment 11

[Alesandro Ortiz]

Re: #c9, the latter should not be a supported scenario. The site can directly link to the protocol, or the site can link/embed a cross-origin page which performs a client-side redirect to protocol (e.g. navigate/embed https://other-site[.]tld/open which loads a page with window.location = 'protocol:').

Agree restricting server-side redirects is a good option. Another option is to update address bar and dialog to reflect origin initiating the dialog, similar to HTTP Auth dialogs (ideally while rendering a blank page in background; Firefox currently keeps the prior page rendered under the cross-origin HTTP Auth dialog.)

Comment 12

[:Gijs (he/him)]

External protocols in server-side redirects probably should be treated similarly to javascript: URLs in server-side redirects

Who wants to bet how many real websites are broken by introducing a restriction like this (e.g. "click this link to email X" -> mailto.cgi?userid=5 -> mailto:[e-mail]) ? Websites do "odd" things to load their external protocols all the time, unfortunately - cf. bug 1650162 for sites loading external URIs from hidden iframes that have no documents in them at all.

should not be a supported scenario

Maybe, but if we end up finding lots of places do it, thinking it a bad idea on its own won't help. :-(

Christoph, can you elaborate a bit on how principals are supposed to deal with redirects, in your understanding? I believe we use the triggering principal to pick the origin to display. I imagine we don't want to update that through redirected loads in general... but then I don't know how else we'd break this type of attack short of the suggestion above, ie banning server-side redirects to external protocols entirely.

(In reply to Alesandro Ortiz from comment #10)

Be advised this behavior also repros in other browsers, and I've filed reports with them. Coordination may be needed if disclosure dates are misaligned.

Thanks for letting us know. Can you link to the relevant tickets? (They'll be restricted, that's fine, but it helps us to keep track of things rather than playing a game of telephone "hey have you had a report of an issue around external protocols" and hoping we find the right one :-) )

Comment 13

[Alesandro Ortiz]

(In reply to :Gijs (he/him) from comment #12)

Who wants to bet how many real websites are broken by introducing a restriction like this (e.g. "click this link to email X" -> mailto.cgi?userid=5 -> mailto:[e-mail]) ? Websites do "odd" things to load their external protocols all the time, unfortunately - cf. bug 1650162 for sites loading external URIs from hidden iframes that have no documents in them at all.

If block redirect approach is used, the restriction can be made only for cross-origin redirects.
e.g. Allowed: https://example[.]com links to https://example[.]com/mailto.cgi?userid=5 which responds with mailto: redirect
e.g. Blocked: https://example[.]com links to https://attacker[.]tld/free-app-upgrade which responds with vulnerable-app://payload redirect

Piping the dialog-initiating origin (https://attacker[.]tld in second example above) into the dialog and related logic probably avoids most compat issues. This would match the safe behavior that currently occurs with HTTP Auth dialogs at the end of a redirect chain: they show the origin of the dialog initiator, not the navigation initiator.

Thanks for letting us know. Can you link to the relevant tickets? (They'll be restricted, that's fine, but it helps us to keep track of things rather than playing a game of telephone "hey have you had a report of an issue around external protocols" and hoping we find the right one :-) )

Chromium: https://crbug.com/1197889 (restricted, of course)
Chromium team indicated their fix will likely fix in Chromium-based Edge, but if that turns out to not be the case, I'll need to file a separate bug with Microsoft.

Comment 14

[Anne (:annevk)]

Thanks for the detailed report Alesandro and taking the time to investigate this!

I agree with Gijs that navigation redirects to custom schemes are very likely so the conservative fix would be to ensure the dialog shows the correct origin. I suppose we could add telemetry to see how often it happens that a cross-origin navigation does such a redirect, but I'd still expect that to be common enough that we cannot break it. (If Chrome pursues this that would change our options. Mike West kindly added me to their issue and they don't have a plan yet. I'll relay if that changes and brief them on our thinking once we settle on something.)

I don't think that's ideal as dialogs showing different origins from the address bar is bad and from that perspective showing a blank page (or mostly opaque) overlay would be attractive, but I'm not sure how feasible that is. Probably not feasible for a short term fix.

(Another dialog not mentioned above that is relevant here is downloads, but we use the final URL there as well.)

Comment 15

[Alesandro Ortiz]

(In reply to Anne (:annevk) from comment #14)

Thanks for the detailed report Alesandro and taking the time to investigate this!

I agree with Gijs that navigation redirects to custom schemes are very likely so the conservative fix would be to ensure the dialog shows the correct origin. I suppose we could add telemetry to see how often it happens that a cross-origin navigation does such a redirect, but I'd still expect that to be common enough that we cannot break it. (If Chrome pursues this that would change our options. Mike West kindly added me to their issue and they don't have a plan yet. I'll relay if that changes and brief them on our thinking once we settle on something.)

I don't think that's ideal as dialogs showing different origins from the address bar is bad and from that perspective showing a blank page (or mostly opaque) overlay would be attractive, but I'm not sure how feasible that is. Probably not feasible for a short term fix.

(Another dialog not mentioned above that is relevant here is downloads, but we use the final URL there as well.)

This bug should now be actionable by the Firefox team:

Chromium has a patch under review that will make the browser "use the origin of the last redirecting server (falling back to the request_initiator if there were no redirects / if the request goes straight to an external protocol)." (source: https://bugs.chromium.org/p/chromium/issues/detail?id=1197889#c25 )

Patch: https://chromium-review.googlesource.com/c/chromium/src/+/3113931

The pending comments are around the tests, not the fix itself, so now seems like a good time to implement a fix in Firefox and/or discuss the fix with the Chromium team if the Firefox team has any concerns.

Let me know if you need more info from me as reporter.

Comment 16

[Anne (:annevk)]

Showing the origin of the last server serving a redirect or the initiating document when there is no redirect is the conservative fix referred to in comment 14. It's not ideal, but better than the status quo.

Comment 17

[Alesandro Ortiz]

Hello,

Friendly ping: Is there an update on this issue?

I've asked Chromium to embargo their crbug to prevent disclosure of the same issue in Firefox. I don't want to keep the Chromium report private for longer than necessary (nor keep Firefox users at risk of this vulnerability), so any update is appreciated.

Comment 18

[:Gijs (he/him)]

(In reply to Alesandro Ortiz from comment #15)

Chromium has a patch under review that will make the browser "use the origin of the last redirecting server (falling back to the request_initiator if there were no redirects / if the request goes straight to an external protocol)." (source: https://bugs.chromium.org/p/chromium/issues/detail?id=1197889#c25 )

To do this this we need a better way of passing this information which is going to require DOM: Security work. Right now we rely on the origin of the triggering principal for the request, which is always the originating site for the initial request. That principal is also not modifiable (I think?) so I don't really know how we would fix this, from a practical/gecko perspective, unless we actually detach the loads rather than treating them as one load, which will probably break other security constructs (same site cookies, referrer info, etc.).

Christoph, can you take a look and/or ensure we prioritize this on the DOM side of things per comment 17?

Comment 19

[:Gijs (he/him)]

Actually something like this:

diff --git a/uriloader/exthandler/nsExternalProtocolHandler.cpp b/uriloader/exthandler/nsExternalProtocolHandler.cpp
--- a/uriloader/exthandler/nsExternalProtocolHandler.cpp
+++ b/uriloader/exthandler/nsExternalProtocolHandler.cpp
@@ -159,17 +159,22 @@ nsresult nsExtProtocolChannel::OpenURL()
 #endif

     RefPtr<mozilla::dom::BrowsingContext> ctx;
     rv = mLoadInfo->GetTargetBrowsingContext(getter_AddRefs(ctx));
     if (NS_FAILED(rv)) {
       goto finish;
     }

-    RefPtr<nsIPrincipal> principal = mLoadInfo->TriggeringPrincipal();
+    RefPtr<nsIPrincipal> principal;
+    if (mLoadInfo->RedirectChainIncludingInternalRedirects().IsEmpty()) {
+      principal = mLoadInfo->TriggeringPrincipal();
+    } else {
+      mLoadInfo->RedirectChainIncludingInternalRedirects().LastElement()->GetPrincipal(getter_AddRefs(principal));
+    }
     rv = extProtService->LoadURI(mUrl, principal, ctx,
                                  mLoadInfo->GetLoadTriggeredFromExternal());

     if (NS_SUCCEEDED(rv) && mListener) {
       mStatus = NS_ERROR_NO_CONTENT;

       RefPtr<nsExtProtocolChannel> self = this;
       nsCOMPtr<nsIStreamListener> listener = mListener;

looks like it "works" - except that then, hardly any of these exploits open a dialog at all -- because the x-domain spoofing mitigation we (okay, I) implemented in bug 1606797 notice that principal A is trying to load an external protocol handler in a browsing context that is currently under the control of principal B, and we block that... I could move the check but that feels like a footgun if we end up adding consumers, or I could pass 2 principals which feels like a recipe for confusion. Passing the loadinfo around would help but would be a bit heavyweight, per Nika's feedback in https://phabricator.services.mozilla.com/D120879 .

Nika or Christoph, do you have thoughts on how to proceed? I think removing the x-frame checks is likely to regress bug 1636654...

Comment 20

[:Gijs (he/him)]

Attachment: Bug 1705211, r?nika!,ckerschb!

Comment 21

[:Gijs (he/him)]

I've just put up a patch to just pass 2 principals, that seems the least terrible here. We can iterate on the patch if need be.

Comment 22

[Alesandro Ortiz]

:Gijs, thanks for the updates and writing the patch. After it's reviewed and lands on Firefox Nightly (or any other channel), please let me know so I can verify the fix.

Comment 23

[:Gijs (he/him)]

Is there a version of the window.location testcase, ie:

(In reply to Alesandro Ortiz from comment #0)

Scenario 2: JavaScript redirect (window.location)

1. Navigate to https://www.google.com/url?q=https%3A%2F%2Faogarantiza.com%2Ffirefox%2Fexternal-protocol%2Fcalc.php&sa=D&sntz=1&usg=AFQjCNEoF7jt2NHEpoTRgtZbbx8F6Na1Gg

that doesn't also have a meta refresh tag? I'd like to make sure both cases are covered.

Comment 24

[Alesandro Ortiz]

(In reply to :Gijs (he/him) from comment #23)

Is there a version of the window.location testcase, ie:

(In reply to Alesandro Ortiz from comment #0)

Scenario 2: JavaScript redirect (window.location)

1. Navigate to https://www.google.com/url?q=https%3A%2F%2Faogarantiza.com%2Ffirefox%2Fexternal-protocol%2Fcalc.php&sa=D&sntz=1&usg=AFQjCNEoF7jt2NHEpoTRgtZbbx8F6Na1Gg

that doesn't also have a meta refresh tag? I'd like to make sure both cases are covered.

There wasn't, but there is now! This page will perform a client-side JavaScript redirect to the "malicious" URL after one second: https://alesandroortiz.com/security/firefox/external-protocol/spoof-js-redirect.html

<script>
  setTimeout(() => {
    window.location = 'https://aogarantiza.com/firefox/external-protocol/calc.php';
  }, 1000);
</script>

Comment 25

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

Landed: https://hg.mozilla.org/integration/autoland/rev/9c044551012e1de039b60aa12431fffcd603db74

Backed out for causing bc test failures on browser_protocol_ask_dialog_external.js:

https://hg.mozilla.org/integration/autoland/rev/6d772f67fc4277dce1675f4b7b2713ecaf9c708b

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&fromchange=74d8d50450823d7aaf5e5262095e414ef1e82868&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Copt%2Cmochitests%2Cwith%2Csoftware%2Cwebrender%2Cand%2Cfission%2Cenabled%2Ctest-linux1804-64-qr%2Fopt-mochitest-browser-chrome-swr-fis-e10s%2Cbc3&tochange=6d772f67fc4277dce1675f4b7b2713ecaf9c708b&selectedTaskRun=P9PohFbvSCiJVJ0Ie5P-2w.1
Failure log: https://treeherder.mozilla.org/logviewer?job_id=359764871&repo=autoland

TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_external.js | Shouldn't have opened a dialog! -
TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_external.js | Test timed out -
TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_external.js | Uncaught exception received from previously timed out test - mocked-protocol-handler observer not removed before the end of test
TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_external.js | Found a tab after previous test timed out: about:blank 

Comment 26

[:Gijs (he/him)]

Bah. Fixed the test and re-queued for landing.

(In reply to Alesandro Ortiz from comment #24)

There wasn't, but there is now!

Thanks! Doublechecked and that too now works with the patch. I'll ping again once this is in Nightly...

Comment 27

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

r=nika,ckerschb
https://hg.mozilla.org/integration/autoland/rev/fcb2c4f7439e7857628e5194ceef5026665b1f72
https://hg.mozilla.org/mozilla-central/rev/fcb2c4f7439e

Comment 28

[:Gijs (he/him)]

OK, this should be in today's nightly, and I believe all the testcases linked to this bug should be fixed. It'd be great if you could confirm that.

Comment 29

[Alesandro Ortiz]

Verified as fixed in Nightly 2021-12-02 on Windows 10, using all PoCs. Thanks for fixing, Gijs!

I thought the fix would also resolve another concerning behavior, but I see it's still reproducible, so I'll file a separate security bug for that in a few hours. It's reproducible with a couple of the PoCs in this report, but fix would be separate and might affect other areas too. Will provide bug ID once filed.

Comment 30

[Alesandro Ortiz]

Actually, the issue was explicitly part of this report (Scenario 5's PoC) and could also be reproduced with Scenario 4's PoC. I've still filed a separate issue since it apparently requires a distinct fix.

See bug 1744158.

Comment 31

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Looks like this needs a tiny bit of rebasing for ESR91. Please attach a rebased patch and request approval when you get a chance.

Comment 32

[Alesandro Ortiz]

Thanks for the reward!

Comment 33

[Alesandro Ortiz]

The related bug 1744158 was fixed a couple of days ago. Verified on Nightly 2021-12-11.

Comment 34

[:Gijs (he/him)]

Attachment: ESR backport patch

Comment 35

[:Gijs (he/him)]

Comment on attachment 9255077 [details] [diff] [review]
ESR backport patch

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-moderate
• User impact if declined: confusing origins in external protocol dialogs
• Fix Landed on Version: 96
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Relatively straightforward patch
• String or UUID changes made by this patch: No string changes; one interface change, but we don't do UUID changes anymore, right? (Should we fix this form?)

Comment 36

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Comment on attachment 9255077 [details] [diff] [review]
ESR backport patch

Approved for 91.5esr.

Comment 37

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/c8fa4ab303fa

Comment 38

[Anca Soncutean, Desktop QA]

Reproduced with Fx 89.0a1 (2021-04-14) on Windows 10.
Verified fixed with Fx 96.0b4 and 91.5esr (treeherder build) on Windows 10.

Comment 39

[Alesandro Ortiz]

Does Mozilla have an automatic disclosure timeline for this type of bug? I'd like to set a date of March 21st, 2022 for public disclosure of this bug and bug 1744158.

Please let me know if the disclosure timeline is acceptable for both bugs.

This allows over 14 weeks for both bug fixes to reach users. Per comment #17, Chromium has embargoed their bug report until the date I request, which will be the same date that Mozilla agrees to here.

Comment 40

[:Gijs (he/him)]

(In reply to Alesandro Ortiz from comment #39)

Does Mozilla have an automatic disclosure timeline for this type of bug? I'd like to set a date of March 21st, 2022 for public disclosure of this bug and bug 1744158.

Please let me know if the disclosure timeline is acceptable for both bugs.

This allows over 14 weeks for both bug fixes to reach users.

Just to be clear, I think you're counting from now, right? Release dates for 96 and 91.5esr are Jan 11, and Jan 11 - March 21st is just under 10 weeks, if I'm not mistaken?

(not a comment on whether that's enough or otherwise, just trying to make sure we're all on the same page!)

I'm afraid I don't know the answer to this, but Dan or Tom should be able to help.

Comment 41

[Alesandro Ortiz]

The response from :dveditz in bug 1744158 included this:

any time after we ship 97 (early February?) is fine

I was counting from when bug 1744158 was marked as fixed, which was December 10th. Google Search and this website calculated that Friday, March 18th would be 14 weeks, so I suggested the following Monday which is March 21st.

If patches for both bugs will be on 96 Stable by mid-January, 2 months is more than reasonable to allow users to update. Based on :dveditz's comment, using March 21st as disclosure date for now.

Comment 42

[:Gijs (he/him)]

(In reply to Alesandro Ortiz from comment #41)

The response from :dveditz in bug 1744158 included this:

any time after we ship 97 (early February?) is fine

Ah, sorry, I didn't see this (this is what I get for reading my needinfos before chasing the rest of my sec-sensitive bugmail...). Then I think the needinfos here are probably superfluous.

Comment 43

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 44

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 45

[Alesandro Ortiz]

Coordinated disclosure date has arrived. Can someone please make this bug public? I've requested the same from Chromium for their related bug.