Persistent Popup DoS with window.print
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: andreien, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Keywords: csectype-dos, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage][adv-main106+][adv-esr102.4+])
Attachments
(5 files)
149 bytes,
text/html
|
Details | |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-esr102+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-esr102+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
248 bytes,
text/plain
|
Details |
I have been testing the window.print functionality in Firefox. At some point, I found that running two print() calls simultaneously in the console (without closing the dialog after the first one) leads to a new browser window opening without any popup permissions. The tab inside the new window is mostly broken, for example it cannot be redirected, but it does get restored by session restore function when quitting firefox.
After a bit of testing different methods to reproduce the parallel nature of this bug within single-threaded JavaScript, I ended up the the following (warning: will keep spawning windows indefinitely, in my case leading to OOM):
window.addEventListener('beforeprint', (event) => {
print()
});
print()
This denial of service is persistent in multiple ways; if the malicious website remains open after session restore, or if the windows open by the malicious website are kept in session restore. When testing this it was difficult to stop the browser because the new windows were stealing focus, exacerbating the issue. Therefore this can lead to persistent full denial of service of browser functionality in the worst case.
This has been tested on Nightly, Mozilla Firefox 106.0a1 20220906092849 20220906092849.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Comment 2•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
If we succeed but return null, we end up retargeting to a new window
here:
Which is bad.
Depends on D156682
Assignee | ||
Comment 4•2 years ago
|
||
Depends on D156683
Updated•2 years ago
|
Comment 6•2 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/85a99403dd29
https://hg.mozilla.org/mozilla-central/rev/a219e399d593
https://hg.mozilla.org/mozilla-central/rev/4cbbc3ea57a0
Comment 7•2 years ago
|
||
Since this could abuse people it'd be nice to wait until this hits release (106) before landing the test.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Is this ready for an ESR approval request? It grafts cleanly.
Assignee | ||
Comment 9•2 years ago
|
||
Comment on attachment 9293485 [details]
Bug 1789439 - Throw rather than logging an error when tab-modal print is already open. r=jwatt,mstriemer
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: comment 0, trivial-ish / simple fix
- User impact if declined: comment 0
- Fix Landed on Version: 106
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Fix is rather trivial. Alternative would be not taking the patch on esr.
Assignee | ||
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Do we also want to uplift https://hg.mozilla.org/mozilla-central/rev/4cbbc3ea57a0 ?
Comment 12•2 years ago
|
||
Comment on attachment 9293485 [details]
Bug 1789439 - Throw rather than logging an error when tab-modal print is already open. r=jwatt,mstriemer
Approved for ESR 102.4.0, thanks.
Updated•2 years ago
|
Comment 13•2 years ago
|
||
uplift |
Updated•2 years ago
|
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
bugherder |
Updated•9 months ago
|
Description
•