Closed Bug 1739220 (CVE-2022-22743) Opened 3 years ago Closed 3 years ago

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)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
97 Branch
Project Flags:
Fission Milestone ?
Tracking Flags:
Tracking Status
firefox-esr91 96+ verified
firefox93 --- disabled
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 + verified
firefox97 + verified

People

(Reporter: sourc7, Assigned: edgar)

References

(Regression)

Details

(Keywords: csectype-spoof, regression, sec-high, Whiteboard: [reporter-external] [client-bounty-form][sec-survey][adv-main96+][adv-ESR91.5+])

Attachments

(4 files)

testcase.html
(deleted), text/html
Details
Firefox - Fullscreen from iFrame then navigate to bfcache lead to Persistent Fullscreen mode on Current Session.mp4
(deleted), video/mp4
Details
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!
(deleted), text/x-phabricator-request
diannaS
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr91+
tjr
: sec-approval+
Details
advisory.txt
(deleted), text/plain
Details
Attached file testcase.html (deleted) —

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:

  1. Visit https://www.google.com to store page on BFCache
  2. Visit attached testcase.html
  3. Click on iFrame element
  4. Browser goes into fullscreen mode then automatically navigate to https://www.google.com
  5. Press "esc" multiple times
  6. Browser stay in fullscreen mode with OS taskbar still visible
Flags: sec-bounty?

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.

Summary: Invoke requestFullscreen from iFrame src with Different Origin then Navigate to Page on bfcache Lead to Persistent Fullscreen Mode for Entire Session → Invoke requestFullscreen from iFrame src with Different Origin then Navigate to Page on bfcache Lead to Persistent Fullscreen Mode for Current Session

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.

Group: firefox-core-security → core-security
Component: Security → DOM: Navigation
Flags: needinfo?(echen)
Keywords: csectype-spoof, sec-high
Product: Firefox → Core
Regressed by: 1715300
Summary: Invoke requestFullscreen from iFrame src with Different Origin then Navigate to Page on bfcache Lead to Persistent Fullscreen Mode for Current Session → Invoke requestFullscreen from iFrame src with Different Origin then Navigate to Page on bfcache Lead to Persistent Fullscreen Mode for Entire Session
Has Regression Range: --- → yes
Keywords: regression
Group: core-security → dom-core-security

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 ¯_(ツ)_/¯

Fission Milestone: --- → ?

Setting status-firefox93=disabled because Fission is disabled by default in Firefox versions <= 93.

status-firefox93: --- → disabled
status-firefox94: --- → ?
status-firefox95: --- → ?
status-firefox96: --- → ?
status-firefox-esr91: --- → disabled

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: nobody → echen
Flags: needinfo?(echen)

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.

Blocks: 1737803
Blocks: 1741280
Attachment #9250820 - Attachment description: Bug 1739220 - Handle fullscreen state in a more reliable way; → Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!

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.
Attachment #9250820 - Flags: sec-approval?

Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!

Approved to land and request uplift

Attachment #9250820 - Flags: sec-approval? → sec-approval+

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 -
Flags: needinfo?(echen)
Flags: needinfo?(echen)

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

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox97: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Group: dom-core-security → core-security-release

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!

status-firefox-esr91: disabled → affected
tracking-firefox-esr91: --- → 96+
Flags: needinfo?(gijskruitbosch+bugs)

I will nominate this for Beta & ESR approval. Thanks!

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(echen)

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
Attachment #9250820 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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.
Flags: needinfo?(echen)
Attachment #9250820 - Flags: approval-mozilla-esr91?

Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!

Approved for 96.0b8

Attachment #9250820 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

Irvan, please check comment 20. I forgot to request information from you in that comment.
Thanks.

Flags: needinfo?(susah.yak)

Comment on attachment 9250820 [details]
Bug 1739220 - Handle fullscreen state in a more reliable way; r=smaug!,Gijs!

Approved for 91.5esr.

Attachment #9250820 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

(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).

Status: RESOLVED → VERIFIED
Flags: needinfo?(susah.yak)

Updating the flag for Firefox97 and waiting to verify the fix on Firefox 96.0b8 and Firefox 91.5esr once they will be landed.

status-firefox97: fixed → verified
QA Whiteboard: [qa-triaged]

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.

QA Whiteboard: [qa-triaged]
status-firefox96: fixed → verified
status-firefox-esr91: fixed → verified
Flags: qe-verify+

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.

Flags: needinfo?(echen)
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][sec-survey]

(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.

Flags: needinfo?(echen)
Flags: sec-bounty? → sec-bounty+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][sec-survey] → [reporter-external] [client-bounty-form][sec-survey][adv-main96+][adv-ESR91.5+]
Attached file advisory.txt (deleted) —
Alias: CVE-2022-22743
Group: core-security-release
Type: task → defect
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: