1668322 - Prevent window.print() stunlocking tech support scam

Status: RESOLVED FIXED

(Core :: Printing: Setup, defect, P2)

Description

[Jonathan Watt [:jwatt]]

I saw this on reddit, and I don't think I've seen it reported in bugzilla:

https://old.reddit.com/r/firefox/comments/igxm5u/this_scam_page_locks_firefox_user_interface_using/

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: test-case?

This seems to work for me (triggers the "prevent this page from creating other dialogs") and so on.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Am I missing something?

Comment 3

[Emma Zühlcke [:emz]]

Perhaps this is a dupe of Bug 1311596? Now with the new print dialog we can probably remove the rate limit prompts.

Comment 4

[Jonathan Watt [:jwatt]]

One of the reddit comments mentions that the page will "detect the dialog blocking and reload the page".

Comment 5

[Jonathan Watt [:jwatt]]

Attachment: testcase (will require TERMINATING your browser if you load this)

This works for me.

Comment 6

[Jonathan Watt [:jwatt]]

It's pretty annoying that both the system print dialog and the "Prevent this page from creating additional dialogues" window blocks the browser from quiting...!

(In reply to Paul Zühlcke [:pbz] from comment #3)

Perhaps this is a dupe of Bug 1311596? Now with the new print dialog we can probably remove the rate limit prompts.

Ah, yeah. Certainly very similar.

The new dialog will certainly help, given it converts the window modal dialog into a tab modal doorhanger. (The user should just be able to close the tab if things get out of hand.) However, the attack throwing fullscreen into the mix makes things more complicated since then the tab close button is hidden.

Maybe we should propagate the value of mAreDialogsEnabled across reloads.

Maybe the "Prevent this page from creating additional dialogues" should be changed to a radio button choice:

• "Prevent this page from creating additional dialogues"
• "Prevent this website from creating additional dialogues"

Comment 7

[Emma Zühlcke [:emz]]

(In reply to Jonathan Watt [:jwatt] from comment #6)

However, the attack throwing fullscreen into the mix makes things more complicated since then the tab close button is hidden.

We could consider leaving dom fullscreen when opening something in the TabDialogBox in general (currently that is system prompts + the print dialog).

Given that the new tab level print dialog can't be spammed anymore, I think we could just remove the rate limit window prompts. That would be removing these calls: https://searchfox.org/mozilla-central/rev/222e4f64b769413ac1a1991d2397b13a0acb5d9d/dom/base/nsGlobalWindowOuter.cpp#5221-5223
Or, ideally we'd know if a print dialog is already open at this point and just drop the calls.

Comment 8

[:Gijs (he/him)]

I'm pretty confused. With the tab modal dialog enabled, both the testcases here allow me to open a new tab and then close the tab with the [x] button on the tab, or to quit the browser on macOS (tested on current macOS nightly). So what's left to fix here? Just the fullscreen case? Where did that come from, as neither testcase here seems to mention / use full screen?

(In reply to Paul Zühlcke [:pbz] from comment #7)

(In reply to Jonathan Watt [:jwatt] from comment #6)

However, the attack throwing fullscreen into the mix makes things more complicated since then the tab close button is hidden.

We could consider leaving dom fullscreen when opening something in the TabDialogBox in general (currently that is system prompts + the print dialog).

This seems like a reasonable plan to me, as we do the same for permission prompts.

Comment 9

[Jonathan Watt [:jwatt]]

(In reply to Paul Zühlcke [:pbz] from comment #7)

Given that the new tab level print dialog can't be spammed anymore, I think we could just remove the rate limit window prompts.

After we remove the old print interface, or at the very least have shipped it to all users and are confident that there are no issues that might crop up and force us to turn it off, sure.

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

I'm pretty confused. With the tab modal dialog enabled...

I'm confused about the confusion. :-) We don't know when we're going to be ready to ship the new tab modal interface, but this scam is apparently something in the wild now. The reddit report and testcases are in the context of the legacy UI.

Just the fullscreen case? Where did that come from, as neither testcase here seems to mention / use full screen?

It comes from the reddit discussion linked in comment 0. Nobody has tried to fully reproduce the in-the-wild DoS code as a testcase yet.

Comment 10

[:Gijs (he/him)]

(In reply to Jonathan Watt [:jwatt] from comment #6)

It's pretty annoying that both the system print dialog and the "Prevent this page from creating additional dialogues" window blocks the browser from quiting...!

This is what the tab modal print dialog is supposed to fix (among other things, of course, but it's part of why it was implemented this way)...

We can fix the "prevent this page" dialog to be tab-modal. I thought that would not help without the tab-modal print dialog, but it would appear that it still blocks further prompts for now (tested with the testcase you attached), which at least allows regaining control of the tab, if the user closes the tab rather than accepting the dialog and expecting it to work...

Maybe we should propagate the value of mAreDialogsEnabled across reloads.

We should put the value on the browsing context and sync it across processes. However, we would then need to clear it for non-same-origin navigation. That doesn't seem trivial, but maybe there are helpers for that kind of thing? Nika, do you know?

Maybe the "Prevent this page from creating additional dialogues" should be changed to a radio button choice:

• "Prevent this page from creating additional dialogues"
• "Prevent this website from creating additional dialogues"

I don't understand what this would really accomplish. I don't think the distinction is meaningful here - this dialog exists solely to avoid spam from pages along the lines of the discussion here. We shouldn't complicate it any more than necessary.

Comment 11

[Jonathan Watt [:jwatt]]

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

Maybe the "Prevent this page from creating additional dialogues" should be changed to a radio button choice:

• "Prevent this page from creating additional dialogues"
• "Prevent this website from creating additional dialogues"

I don't understand what this would really accomplish. I don't think the distinction is meaningful here - this dialog exists solely to avoid spam from pages along the lines of the discussion here. We shouldn't complicate it any more than necessary.

I had in mind the reloading the script was using when window.print() throws to get around the "Prevent this page from creating additional dialogues" prompt. We could have the prompt block dialogues from that page for the entire session, say. But then I guess attackers might redirect to a different path on the site rather than reloading. Going one step further along the arms race I guess was to block dialogues for the entire site. Of course it would only make attacks a little more complicated, rather than stopping them.

It does raise the question why window.print() throws though. Probably it should just silently fail. Although I guess that's also detectable via the lack of print events, unless we were to dispatch those events anyway.

Comment 12

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

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

(In reply to Jonathan Watt [:jwatt] from comment #6)

Maybe we should propagate the value of mAreDialogsEnabled across reloads.

We should put the value on the browsing context and sync it across processes. However, we would then need to clear it for non-same-origin navigation. That doesn't seem trivial, but maybe there are helpers for that kind of thing? Nika, do you know?

If we did something like that, it would be relatively simple to circumvent the restriction by repeatedly navigating between two different origins both controlled by the attacker rather than reloading. Perhaps it would increase the burden of implementing this kind of scam attack enough that they wouldn't do it anymore though.

:baku recently did something similar-ish with a field being reset whenever doing a cross-origin navigation with bug 444222 (old bug, fixed quite recently). Perhaps the code added in that patch could be generalized to also handle resetting this value?

Comment 13

[Jonathan Watt [:jwatt]]

Probably another example of this being reported on SUMO: https://support.mozilla.org/en-US/questions/1311430

Comment 14

[Daniel Bodea [:danibodea]]

I could not reproduce this issue with either of the 2 test cases in Nightly v87.0a1, v79.0a1 or v78.0a1 in Windows 10. The dialog prevention modal worked and successfully stopped the print page from reloading.

I have succeeded in reproducing the issue on Ubuntu 20 and Mac OS 11.2 with the second test case. When clicking Cancel on the print dialog, and then clicking OK on the "Prevent this page from creating additional dialogs" modal is displayed, the page is being reloaded and the print modal is displayed again.

In the latest Nightly, On Mac OS, both the print and dialog prevention modals prevent the user from closing the tab so the browser needs to be force closed to avoid this loop. On Ubuntu 20, the dialog prevention modal is blocking the user from closing the tab, but the print modal isn't, so this issue is a blocker only on Mac OS (this is not the case in older versions like RC v86.0 and older).

In conclusion, this bug is not reproducible on Windows 10, partially reproducible on Ubuntu 20 and totally reproducible on Mac OS 11.2 with TC in comment 5.

Comment 15

[Daniel Bodea [:danibodea]]

Meant to ask how to reproduce, but found out how by testing other platforms. Nevermind the information request.

Comment 16

[:Gijs (he/him)]

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

We can fix the "prevent this page" dialog to be tab-modal. I thought that would not help without the tab-modal print dialog, but it would appear that it still blocks further prompts for now (tested with the testcase you attached), which at least allows regaining control of the tab, if the user closes the tab rather than accepting the dialog and expecting it to work...

I've seen the fact that this dialog isn't tab-modal brought up elsewhere (can't remember where off the top of my head). Paul, any reason not to just do that to take (the rest of) the sting out of this issue?

Comment 17

[Emma Zühlcke [:emz]]

As mentioned in comment 7 I think we should just remove the anti-DoS confirmation dialog for the print case. Now that we've shipped the tab-modal print dialog which isn't susceptible to this attack anymore there is no need to keep it.
As a side note, this would also fix Bug 1697811.

Comment 18

[Emma Zühlcke [:emz]]

If we still find a way to DoS here we'd need to keep it. In that case we should make the confirm prompt itself tab-modal.

Comment 19

[Emma Zühlcke [:emz]]

We can probably keep it for cases where the new dialog isn't enabled or we don't show one at all:

  const bool printTabModal = StaticPrefs::print_tab_modal_enabled() &&
                         !StaticPrefs::print_always_print_silent();

  if (!printTabModal && ShouldPromptToBlockDialogs() && !ConfirmDialogIfNeeded()) {
    return aError.ThrowNotAllowedError("Prompt was canceled by the user");
  }

I'm waiting for a build to see if there are still DoS issues in this configuration.

Comment 20

[Emma Zühlcke [:emz]]

Attachment: Bug 1668322 - Disable anti-dos confirmation prompt for tab level print dialogs. r=emilio!

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/588adb54219c
Disable anti-dos confirmation prompt for tab level print dialogs. r=emilio

Comment 22

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/588adb54219c

Comment 23

[Timea Zsoldos [:tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 83.0a1 (2020.09.30) on Win 8.1 x64 and Ubuntu 20.04 x64.
I can confirm this issue is fixed, I verified using Firefox 88.0 on Win 8.1 x64, macOS 11.2 and Ubuntu 20.04 x64.