Invoke requestFullscreen from iFrame src with Different Origin then Navigate to Page on bfcache Lead to Persistent Fullscreen Mode for Entire Session
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: sourc7, Assigned: edgar)
References
(Regression)
Details
(4 keywords, Whiteboard: [reporter-external] [client-bounty-form][sec-survey][adv-main96+][adv-ESR91.5+])
Attachments
(4 files)
208 bytes,
text/html
|
Details | |
1.41 MB,
video/mp4
|
Details | |
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr91+
tjr
:
sec-approval+
|
Details | Review |
219 bytes,
text/plain
|
Details |
After iFrame on different origin invoke requestFullscreen()
then parent page navigate to page on bfcache, the browser will goes into fullscreen with OS taskbar still visible, interestingly after pressing "esc" multiple times it will not exit the browser fullscreen mode for the entire current session. For me the only way to exit the browser is from OS taskbar or task manager taskill.
I can only reproduce this on Fission enabled and fission.bfcacheInParent
toggled to true
which the default since commit Enable BFCache in parent when Fission is enabled.
Steps to reproduce:
- Visit https://www.google.com to store page on BFCache
- Visit attached testcase.html
- Click on iFrame element
- Browser goes into fullscreen mode then automatically navigate to https://www.google.com
- Press "esc" multiple times
- Browser stay in fullscreen mode with OS taskbar still visible
Reporter | ||
Comment 1•3 years ago
|
||
Reporter | ||
Comment 2•3 years ago
|
||
Ok, it turns out the fullscreen mode can be exited if navigate to different origin while page on fullscreen. I tried that recently when browser in fullscreen mode on https://www.google.com page then I search Mozilla and navigate to Mozilla website the browser no longer in fullscreen.
In real case to achieve the persistent fullscreen mode for entire session, attacker can change the location.href
to their spoof website, so user will not able to navigate to different origin.
Comment 3•3 years ago
|
||
The framed document is simply the following (in case it goes away)
<html onclick="document.documentElement.requestFullscreen()">
</html>
If you start from a not-quite-maximized window you'll see that it's not really "full" screen, but you go back to the original window size. But the browser chrome is gone! Perfect for spoofing the full toolbar. I think you just had a maximized window to begin with and you're seeing what I'm seeing. It's a little more obvious what's happening on a Mac because the system toolbar comes back at the top, although that's essentially what you're getting with the Windows dock at the bottom.
Not sure where "bfcache" comes into this. I can reproduce if I skip step 1. (I'm currently in that state and don't know how to get out without restarting Firefox :-) ). I'm mystified why that would have anything at all to do with missing chrome.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
navigating didn't seem to help, but I was closing tabs in this window and the chrome just came back after half a dozen or so ¯_(ツ)_/¯
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Setting status-firefox93=disabled because Fission is disabled by default in Firefox versions <= 93.
Assignee | ||
Comment 6•3 years ago
|
||
regression window from mozregression,
16:16.53 INFO: Last good revision: ab936b7f0c9f9e0b27e42e3f7909131bface08b9
16:16.53 INFO: First bad revision: 7d32671931b7c2f5cb24b0f4d62bb6884e484175
16:16.53 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ab936b7f0c9f9e0b27e42e3f7909131bface08b9&tochange=7d32671931b7c2f5cb24b0f4d62bb6884e484175
It looks like something related to BFCache in parent, and if I disable BFCache in parent, I could not reproduce this.
Assignee | ||
Comment 7•3 years ago
|
||
Assignee | ||
Comment 8•3 years ago
|
||
Before the BFCache is enabled for fission, the window actor will be destroyed after page navigates away, then it will trigger to clear fullscreen state in browser window. But now window actor might not be destroyed and gets confused regarding the fullscreen state.
Updated•3 years ago
|
Assignee | ||
Comment 9•3 years ago
|
||
Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
Security Approval Request
- How easily could an exploit be constructed based on the patch?: The patch shows the issue is something related to fullscreen, but I don't think it is trivial to know where the exact problem is.
- Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
- Which older supported branches are affected by this flaw?: All
- If not all supported branches, which bug introduced the flaw?: None
- Do you have backports for the affected branches?: No
- If not, how different, hard to create, and risky will they be?: Probably not hard to create backports.
- How likely is this patch to cause regressions; how much testing does it need?: This patch makes us more reliable in cleanup the fullscreen state for various cases, this should not affect most "general" cases. We have many fullscreen tests for "general" cases, I also do some stress tests with the tests attached in bug 1741280. But it's still possible (though unlikely) that will cause unexpected results. It would be better to monitor Nightly a bit before uplift.
Comment 10•3 years ago
|
||
Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
Approved to land and request uplift
Comment 11•3 years ago
|
||
Backed out for causing multiple failures e.g. browser_media_control_non_eligible_media.js.: https://hg.mozilla.org/integration/autoland/rev/9f93d8cd92328c14ba6acfde46e314b5494cc490
push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=f69aa1b07b51234c268feea814ef19fa7a3cf94a
failure log:
TEST-UNEXPECTED-FAIL | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out. -
TEST-UNEXPECTED-FAIL | dom/media/mediacontrol/tests/browser/browser_media_control_non_eligible_media.js | Test timed out -
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 12•3 years ago
|
||
Handle fullscreen state in a more reliable way; r=smaug,Gijs
https://hg.mozilla.org/integration/autoland/rev/d36a4319b5d4a051abbc5c646d134ab48d706e87
https://hg.mozilla.org/mozilla-central/rev/d36a4319b5d4
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Sounds like we need this on all branches after all. Gijs, can you please nominate this for Beta & ESR approval since Edgar is on PTO? It grafts cleanly. Thanks!
Assignee | ||
Comment 15•3 years ago
|
||
I will nominate this for Beta & ESR approval. Thanks!
Assignee | ||
Comment 16•3 years ago
|
||
Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
Beta/Release Uplift Approval Request
- User impact if declined: When an iframe is in fullscreen and the parent page navigates away, the browser window might be stuck in fullscreen mode and might cause the user to be spoofed.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Follow the STR in comment #0
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): This patch makes us more reliable in cleanup the fullscreen state for various cases, this should not affect most "general" cases. We have many fullscreen tests for "general" cases, I also do some stress tests with the tests attached in bug 1741280. But it's still possible (though unlikely) that will cause unexpected results given the changes aren't small.
- String changes made/needed: None
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 17•3 years ago
|
||
Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: It is a sec-high bug.
- User impact if declined: When an iframe is in fullscreen and the parent page navigates away, the browser window might be stuck in fullscreen mode and might cause the user to be spoofed.
- Fix Landed on Version: 97
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): This patch makes us more reliable in cleanup the fullscreen state for various cases, this should not affect most "general" cases. We have many fullscreen tests for "general" cases, I also do some stress tests with the tests attached in bug 1741280. But it's still possible (though unlikely) that will cause unexpected results given the changes aren't small.
Comment 18•3 years ago
|
||
Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
Approved for 96.0b8
Comment 19•3 years ago
|
||
uplift |
Comment 20•3 years ago
•
|
||
I managed to reproduce the issue on Firefox 95.0.2, I couldn't reproduce it on Firefox Nightly 97.0a1 (2021-11-03) (64-bit) or any older Nightly version.
The issue is not reproducible on the latest Firefox Nightly 97.0a1 (2021-12-20) but neither on any older Firefox Nightly versions.
Irvan, could you please check if the issue is fixed on the latest Firefox Nightly on your side?
Thanks.
Comment 21•3 years ago
•
|
||
Irvan, please check comment 20. I forgot to request information from you in that comment.
Thanks.
Comment 22•3 years ago
|
||
Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
Approved for 91.5esr.
Comment 23•3 years ago
|
||
uplift |
Reporter | ||
Comment 24•3 years ago
|
||
(In reply to Hani Yacoub from comment #20)
I managed to reproduce the issue on Firefox 95.0.2, I couldn't reproduce it on Firefox Nightly 97.0a1 (2021-11-03) (64-bit) or any older Nightly version.
The issue is not reproducible on the latest Firefox Nightly 97.0a1 (2021-12-20) but neither on any older Firefox Nightly versions.
Irvan, could you please check if the issue is fixed on the latest Firefox Nightly on your side?
Thanks.
Thanks Edgar for the fix! I able to reproduce this on Firefox 95.0.1 (64-bit) MSIX, I confirm this has been fixed on my side on Firefox Nightly 97.0a1 (2021-12-21) (64-bit).
Comment 25•3 years ago
|
||
Updating the flag for Firefox97 and waiting to verify the fix on Firefox 96.0b8 and Firefox 91.5esr once they will be landed.
Updated•3 years ago
|
Comment 26•3 years ago
|
||
Verified as fixed on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04 x64 on Firefox 96.0b8 and on Firefox 91.5.0esr.
Comment 27•3 years ago
|
||
As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.
Please visit this google form to reply.
Assignee | ||
Comment 28•3 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #27)
As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.
Please visit this google form to reply.
Done.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 29•3 years ago
|
||
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•6 months ago
|
Description
•