1756388 - (CVE-2022-31738) requestFullscreen on iFrame from different origin able to not show fullscreen notification toast

Status: VERIFIED FIXED

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

Description

[Irvan Kurniawan [:sourc7]]

Attachment: 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

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: Firefox - requestFullscreen on iFrame from different origin able not show fullscreen notification toast.mp4

Comment 2

[Daniel Veditz [:dveditz]]

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

Comment 3

[Irvan Kurniawan [:sourc7]]

Attachment: 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.

Comment 4

[Irvan Kurniawan [:sourc7]]

Attachment: Firefox - requestFullscreen on iFrame different origin without fullscreen notification toast.mp4

Comment 5

[Irvan Kurniawan [:sourc7]]

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.

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Irvan Kurniawan [:sourc7]]

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

Comment 8

[Irvan Kurniawan [:sourc7]]

Attachment: Screenshot_20220407_055608.png

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.

Comment 9

[Daniel Veditz [:dveditz]]

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

Comment 10

[Edgar Chen [:edgar]]

Attachment: Bug 1756388;

Comment 11

[Edgar Chen [:edgar]]

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

Comment 12

[Tom Ritter [:tjr]]

Comment on attachment 9273088 [details]
Bug 1756388;

Approved to land and uplift

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

r=smaug
https://hg.mozilla.org/integration/autoland/rev/649541d1dfb196872c65218c5faec2725b8d74ab
https://hg.mozilla.org/mozilla-central/rev/649541d1dfb1

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Landed for 101.0b3.
https://hg.mozilla.org/releases/mozilla-beta/rev/202ad884dcbf

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/b25038f89d63

Comment 16

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 and on Windows 11.

Comment 17

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 and on Windows 11.

Comment 18

[Tom Ritter [:tjr]]

Attachment: advisory.txt