1888695 - (CVE-2024-5691) Iframe sandbox bypass via clickjacking on the native XFO error page.

Status: VERIFIED FIXED

(Core :: DOM: Security, defect, P2)

Description

[Luan Herrera]

Attachment: repro-video.mov

A sandboxed iframe is not supposed to be able to initiate downloads or open popups unless the "allow-downloads" or "allow-popups" flags are respectively set. However, it is possible to trick users into clicking on the "Open Site in New Window" button that is displayed in error pages that opt-out from being embedded through the usage of the X-Frame-Options header. This functionality currently does not check whether the page is sandboxed before opening the new window, effectively allowing a clickjacking attack to occur on it and thus bypass the iframe sandbox protections.

A simple fix for this issue would be to disable the "Open Site in New Window" button if the iframe is sandboxed without the proper flags being set (allow-popups and allow-downloads).

For the attack to work, it requires the victim to click once inside a malicious iframe. The PoC provided just places opacity over the iframe to demonstrate that it would be possible to completely overlay the native Firefox error page and display whatever the attacker wanted instead.

I have attached a video (repro-video) reproducing the attack.

VERSION
Version: 124.0.1 (64-bit).
Operating System: MacOS 14.1.1 (23B81).

REPRODUCTION CASE

1. Access https://lbherrera.github.io/lab/firefox/iframe-sandbox/victim-0019884.html
2. Click on the first "Open Site in New Window" button and a new window will open.
3. Click on the second "Open Site in New Window" button and a download will start.

CREDIT INFORMATION
Reporter credit: Luan Herrera (@lbherrera_)

Comment 1

[Andrew McCreight [:mccr8]]

If anybody else is confused like me about what is going on here, bug 1461195 is what added the "Open Site in New Window" button when CSP or whatever blocks the loading of the iframe. There are some screen shots of what it looks like when it isn't so small.

Comment 2

[Daniel Veditz [:dveditz]]

What the button does is automate what people could do before, which was right-click on the blocked frame and choose "Open Frame in New Tab", which in turn was a shortcut for viewing the frame info, manually copying the url, and then pasting it into a new tab. You can do "Open Frame in New Tab" on the middle "attacker-0019884.html" frame and that's not considered a sandbox violation. But of course you can't trick a user into doing that with single a click like you can here; that's unexpected, and violates the sandbox.

I don't see any tests for my warning from bug 1461195 comment 5, but SameSite=Strict cookies are correctly suppressed. I think that's just a natural consequence of the fact that about:netError is not https://www.google.com and not because the error page is consciously aware of any security policies. Without using the correct triggering origin we can't propagate the correct sandbox or CSP policies. Unfortunately, about:netError is not a system-privileged context so it can't use the correct triggeringPrincipal if it wanted to.

Mccr8 suggested one quick fix would be to hide the button if the context is in a sandbox or should inherit a CSP. The error page itself can't even find out that it's in a sandboxed or CSP state unless those are passed in as parameters, but that could be done.

Another thing we could do is use an intersection observer to disable or hide the button if too little of the context is shown. That would not fix the problem of not using the right security policy, but at least the user would be opening the content on purpose.

Violating these two sandbox rules isn't very severe—these are more "anti-annoyance" features and so people don't blame the wrong site (the top-level) for what a 3rd party did. The download could be worse than the popup. But worse than the annoyance of a popup, the new tab launched from this button is no longer bound by the sandbox, as a popup would be in the "allow-popups" case. I suspect this could be a CSP escape, too, although CSP is propagated only in narrow circumstances (only srcdoc/about:blank and data: documents).

In contrast, Safari just shows a blank frame and Chrome shows a grey "sad-page" icon (if you hover over the frame they will add text saying "www.example.com refused to connect"). We should think of getting rid of the button entirely: why does it need to be easy to get to content that didn't want to be shown in that context? Why does the parent page frame this site that results in a broken experience on their page? Maybe it's an old unmaintained page, but more likely they're up to no good, like Luan's example here. Firefox is already more helpful than other browsers by supporting the "Open Frame in New Tab" context-menu item, and if you can't find that you might also not be aware of the risks of blindly clicking the button. The site could have just had a link to the content instead of trying to frame it.

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: sandboxed frames testcase

Note that in the proper sandbox=allow-popups cases the sandbox propagates to the new tab. Windy.com is non-functional without JavaScript, and Twitter has a cross-origin-opener-policy violation.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1461195

Comment 5

[Tom Schuster (MoCo)]

Attachment: Bug 1888695 - Add a pref for the iframe XFO/CSP Open In New Window button. r?dveditz

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1461195

Comment 7

[Tom Schuster (MoCo)]

I am currently having issues with the new test that I added. On the try test verification run, but not locally with ./mach test --verify, I get the following error:

[task 2024-04-24T10:32:41.050Z] 10:32:41     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/about/browser_aboutNetError_csp_iframe_no_openinwindow.js | Uncaught exception in test bound test_csp - undefined - threw exception: AbortError: Actor 'SpecialPowers' destroyed before query 'Spawn' was resolved

https://treeherder.mozilla.org/logviewer?job_id=455654905&repo=try&lineNumber=17388

It sounds like awaiting SpecialPowers.spawn is somehow not working, but I can't see the issue and this is similar to the existing test.

Comment 8

[Tom Schuster (MoCo)]

Attachment: WIP: Bug 1888695 - Add test

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3567557cdeb1
Add a pref for the iframe XFO/CSP Open In New Window button. r=dveditz

Comment 10

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

https://hg.mozilla.org/mozilla-central/rev/3567557cdeb1

Comment 11

[Tom Schuster (MoCo)]

I've landed this without the test for now, but I will try to figure out how to get the test past treeherder.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:tschuster, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox126 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[Tom Schuster (MoCo)]

Dan, do you think we should uplift this to beta? It does seem to apply cleanly, but I also don't think this a really critical issue.

Comment 14

[Donal Meehan [:dmeehan]]

Fx126 beta cycle has finished.
126.0 RC1 is being prepared.
Could this ride the train with Fx127 and get an uplift for the corresponding 115esr? (115.12esr)

Comment 15

[Donal Meehan [:dmeehan]]

Confirmed over slack that this can ride the train for Fx127.
Please add an ESR115 uplift request

Comment 16

[Daniel Veditz [:dveditz]]

I agree with Donal and Tom's slack decision.

Comment 17

[Tom Schuster (MoCo)]

Attachment: Bug 1888695 - Add a pref for the iframe XFO/CSP Open In New Window button. r?dveditz

Original Revision: https://phabricator.services.mozilla.com/D206911

Comment 18

[Tom Schuster (MoCo)]

Attachment: Bug 1888695 - Add a pref for the iframe XFO/CSP Open In New Window button. r?dveditz

Original Revision: https://phabricator.services.mozilla.com/D206911

Comment 19

[Tom Schuster (MoCo)]

Attachment: Bug 1888695 - Add a pref for the iframe XFO/CSP Open In New Window button. r?dveditz

Original Revision: https://phabricator.services.mozilla.com/D206911

Comment 20

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Click jacking in a sandbox iframe allows opening a window
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Open https://lbherrera.github.io/lab/firefox/iframe-sandbox/victim-0019884.html. Make sure there is no "Open Site in New Window" button.
• Risk associated with taking this patch: low
• Explanation of risk level: Disables an optional button that no other browser has.
• String changes made/needed: none
• Is Android affected?: yes

Comment 21

[Ciprian Georgiu, Desktop QA]

I've reproduced this issue using an affected Nightly build (2024-03-29) on macOS 13.

The issue is verified as fixed on latest Nightly 127.0a1 under macOS 13, Ubuntu 20.04 and Win 11.

Comment 22

[Pascal Chevrel:pascalc]

The patch failed to land on the esr115 branch, could you rebase your patch? Thanks
https://lando.services.mozilla.com/D209784/

Comment 23

[Tom Schuster (MoCo)]

I think this should work now. (Locally this rebase just worked)

Comment 24

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/146b61f526c7

Comment 25

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 26

[Ciprian Georgiu, Desktop QA]

This is also verified as fixed on 115.12.0 ESR with Win 11, macOS 14 and Ubuntu 22.04.