Closed Bug 1756388 (CVE-2022-31738) Opened 2 years ago Closed 2 years ago

requestFullscreen on iFrame from different origin able to not show fullscreen notification toast

Categories

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

defect

Tracking

()

VERIFIED FIXED
102 Branch
Tracking Status
firefox-esr91 101+ verified
firefox100 --- wontfix
firefox101 + verified
firefox102 + verified

People

(Reporter: sourc7, Assigned: edgar)

References

Details

(Keywords: csectype-spoof, reporter-external, sec-high, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main101+][adv-esr91.10+])

Attachments

(7 files)

Attached file iframegcloud.html

After trigger requestFullscreen on iFrame from different origin, then click the iFrame to navigate the iFrame url, interestingly after browser exit the fullscreen mode, the iFrame content escaped to parent page.

It seems the browser is improperly exit the fullscreen mode, the page still looks on fullscreen mode, but with visible address bar and toolbar. Interestingly when in that situation, after trigger requestFullscreen the browser goes into fullscreen without fullscreen notification toast.

Tested on:

  • Firefox 97.0.1 (64-bit) on Windows 11
  • Firefox Nightly 99.0a1 (2022-02-20) (64-bit) on Windows 11

Steps to reproduce:

  1. Visit attached iframegcloud.html
  2. Click anywhere inside the iFrame
  3. Click "AAA" href text
  4. Click Spoof page
  5. Browser goes fullscreen without fullscreen notification toast
Flags: sec-bounty?
Summary: requestFullscreen on iFrame content able to not show fullscreen notification toast → requestFullscreen on iFrame from different origin able to not show fullscreen notification toast
Group: firefox-core-security → dom-core-security
Component: Security → DOM: Core & HTML
Product: Firefox → Core

I'm not able to reproduce this on Mac: could be Windows-only as with other recent fullscreen bugs.

Flags: needinfo?(echen)
Attached file iframegcloud2.html

Alright I've created new testcase, the STR just simply click the page, and now it works on Linux (including x11 and wayland) and Windows 11.

When checking with mozregression using new testcase then rollback the build, I can reproduce this since commit Bug 1505916 - [Fission] Make the fullscreen code Fission-aware
and browser.tabs.documentchannel and fission.autostart set to true.

Looks like the DOMFullscreen code needs to be refactored to address this issue.

I can reproduce on Mac with the testcase from comment 3

The black content appears to be the transition frame in between the browser view and the fullscreen view. Can you actually show spoofy content with this attack? Black is just a kind of DOS -- users might think their screen died maybe and freak out? The dangerous abuse of fullscreen is when you can fool the user into thinking it is NOT fullscreen and therefore the displayed "browser" is the real browser and not a construct.

Flags: needinfo?(susah.yak)

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

I can reproduce on Mac with the testcase from comment 3

The black content appears to be the transition frame in between the browser view and the fullscreen view. Can you actually show spoofy content with this attack? Black is just a kind of DOS -- users might think their screen died maybe and freak out? The dangerous abuse of fullscreen is when you can fool the user into thinking it is NOT fullscreen and therefore the displayed "browser" is the real browser and not a construct.

Thanks Dan for the update.

Yes, it possible to spoof the page. I think the black is from the Firefox following dark theme scheme (I also see black on Chromium) when browser switch to fullscreen on page without explicitly set CSS background-color.

I've just added * { background-color: white } to the spoofxbm1.html (iFrame content on comment 3) so the background page turns white and spoof text is now visible. (Tested on Firefox Nightly 101.0a1 (2022-04-06) (64-bit)).

Flags: needinfo?(susah.yak)

This is what I see now using testcase on comment 3, reproduced on Firefox Nightly 101.0a1 (2022-04-06) (64-bit) on Arch Linux.

On Mac the testcase in comment 3 didn't work the first click (it entered and then exited fullscreen), but worked the second

Assignee: nobody → echen
Severity: -- → S2
Flags: needinfo?(echen)
Blocks: 1765559
Attached file Bug 1756388;

Comment on attachment 9273088 [details]
Bug 1756388;

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 construct a exploit based on it.
  • 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?: I would expect this patch could be applied directly
  • 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 them. I also do some stress tests with the tests attached in bug 1765559. But it's still possible (though unlikely) that will cause unexpected results. It would be better to monitor Nightly a bit before uplift.
  • Is Android affected?: No
Attachment #9273088 - Flags: sec-approval?

Comment on attachment 9273088 [details]
Bug 1756388;

Approved to land and uplift

Attachment #9273088 - Flags: sec-approval?
Attachment #9273088 - Flags: sec-approval+
Attachment #9273088 - Flags: approval-mozilla-esr91+
Attachment #9273088 - Flags: approval-mozilla-beta+
Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Verified as fixed on Windows 10 and on Windows 11.

Verified as fixed on Windows 10 and on Windows 11.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Flags: sec-bounty? → sec-bounty+
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main101+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main101+] → [reporter-external] [client-bounty-form] [verif?][adv-main101+][adv-esr91.10+]
Alias: CVE-2022-31738
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: