1801501 - (CVE-2023-6210) Mixed content bypass using window.open'd about:blank from http context and https iframe

Status: RESOLVED FIXED

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

Description

[Godson Bastin]

Attachment: index.html

Browser used: Firefox's latest version

Hi Team,

I Just Read a disclosed Chrome Report and Seems the Same Bug affecting Firefox's Latest Version.
https://bugs.chromium.org/p/chromium/issues/detail?id=957002 (It is possible to Frame HTTP Site from HTTPS which is not allowed and it will throw a "Mixed Content" error)

Steps to Reproduce,

1 . To demonstrate the issue, you will need 2 Websites. One with HTTP and another with HTTPS.
2. From HTTPS, You need to Open a Javascript URI with
var newWin = window.open("javascript:''","_blank");
3. Then Call InnerHTML on newWin with iframe.src as HTTP Site,
newWin.document.body.innerHTML = "<iframe src='http://testphp.vulnweb.com/login.php'>"

I have added the PoC URL and PoC.html for reference.

Thanks,
Godson

Comment 1

[Godson Bastin]

I forgot to mention that, Kindly enable Allow Popups on HTTPS (POC Site) site

Comment 2

[Daniel Veditz [:dveditz]]

The main reason for blocking insecure iframes is that the user has no way to know if it's insecure or not. It's not otherwise dangerous on its own, and an "about:blank" page isn't making any security promises. But I'll have to try writing into the containing document -- I think you can get the URL to change to the page that writes it out. Then again, that might trigger proper mixed-content behavior

To test, make sure HTTPS-Only mode is disabled!

Comment 3

[Daniel Veditz [:dveditz]]

This is a case where having an actual "policy container", rather than "behaving as if" would help. Are there other security policies we're dropping here, like escaping an iframe sandbox or CSP restrictions?

Comment 4

[Godson Bastin]

Hi Daniel, Sorry for the delayed response. I didn't manage to find any CSP bypass or sandbox bypass.

Comment 5

[Daniel Veditz [:dveditz]]

I had thought this might be related to bug 1803475 and bug 1804145, but those turned out to be specific to the CSP code. My comment 3 is likely wrong for that reason, and in addition, debug logging shows the MixedContentBlocker gets the correct context from LoadInfo:

MCBLog shouldLoad:
MCBLog   - contentLocation: http://testphp.vulnweb.com/login.php
MCBLog   - internalContentPolicyType: TYPE_INTERNAL_IFRAME
MCBLog   - loadingPrincipal: https://random.0xgodson.com/mixed-content-bypass-r4nd0m.html
MCBLog   - triggeringPrincipal: https://random.0xgodson.com/mixed-content-bypass-r4nd0m.html
MCBLog   - URISafeToBeLoadedInSecureContext:
MCBLog     - schemeLocal: 0
MCBLog     - schemeNoReturnData: 0
MCBLog     - schemeInherits: 0
MCBLog     - schemeSecure: 0

... and then it exits ShouldLoad through one of the returns that does no further logging :-(

A check of the InnermostURI for a literal https: scheme looked promising, but as the logging above shows it's using the correct starting principal (not window.location), plus it would have logged this result.

The parent document window.isSecureContext is true, but does TopWindowContext() return something else?

Clearly something is going wrong here in the mixed content blocker, but I'm satisfied it's localized to this code and not a more general about:blank policy context problem that might affect more impactful checks. the sec-low rating is appropriate.

Comment 7

[June Wilde (she/her) [:jewilde]]

Attachment: Bug 1801501 - Check if rootDoc is secure context for web compat; r=ckerschb

Comment 8

[Frederik Braun [:freddy]]

This might end up fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1474842, best to check again when this lands (OK if it doesn't though)

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e4bf227a6224
Check if rootDoc is secure context for web compat; r=ckerschb

Comment 10

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

Backed out for causing mochitest plain failures on test_windowOpen.html:
https://hg.mozilla.org/integration/autoland/rev/dd0a1589ba3145eb90860df2090308b7ee4cc650

Push with failures
Failure log

dom/security/test/mixedcontentblocker/test_windowOpen.html | error thrown for failed iframe load should be from test1's iframe. - got undefined, expected "https://test1.example.com/tests/dom/security/test/mixedcontentblocker/file_windowOpen.html"

Comment 11

[June Wilde (she/her) [:jewilde]]

thanks Aryx! currently investigating

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8fef15085b15
Check if rootDoc is secure context for web compat; r=ckerschb

Comment 13

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

Backed out for causing several mochitest failures:
https://hg.mozilla.org/integration/autoland/rev/3a9b1cfd0fde999b04d7f964988b768f7bfd0266

Push with failures
Failure log

dom/security/test/mixedcontentblocker/test_windowOpen.html | uncaught exception - SecurityError: Permission denied to access property "docShell" on cross-origin object at get/<@resource://testing-common/WrapPrivileged.sys.mjs:264:25

More failures:

• https://treeherder.mozilla.org/logviewer?job_id=430276310&repo=autoland
• https://treeherder.mozilla.org/logviewer?job_id=430280737&repo=autoland

Comment 14

[June Wilde (she/her) [:jewilde]]

thanks! looking now

Comment 15

[Christoph Kerschbaumer [:ckerschb}]

Hey June, I think you can mark that test as skip-if xorigin, details:
https://searchfox.org/mozilla-central/rev/fd2325f5b2a5be8f8f2acf9307285f2b7de06582/dom/security/test/csp/mochitest.ini#295

Comment 16

[June Wilde (she/her) [:jewilde]]

thanks Christoph!

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b8981c31d4b9
Check if rootDoc is secure context for web compat; r=ckerschb

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b8981c31d4b9

Comment 19

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

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

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

For more information, please visit BugBot documentation.

Comment 20

[June Wilde (she/her) [:jewilde]]

I think this is fine to ride the trains without uplift.
If we do decide that this would be worth the hassle uplifting then we'd likely want to uplift the patch for Bug 1855588 as well

Comment 21

[Daniel Veditz [:dveditz]]

Attachment: advisory.txt

Comment 22

[Godson Bastin]

Hey team,
Thanks for the bounty and CVE.

If I can ask, can you please update the reporter/credit name from "0xgodson" to "Godson Bastin" on both CVE and mozilla page?

Thanks again,
Godson.

Comment 23

[:Gijs (he/him)]

(In reply to Godson Bastin from comment #22)

Hey team,
Thanks for the bounty and CVE.

If I can ask, can you please update the reporter/credit name from "0xgodson" to "Godson Bastin" on both CVE and mozilla page?

Thanks again,
Godson.

--> :tjr

Comment 24

[Frederik Braun [:freddy]]

Fixed in https://github.com/mozilla/foundation-security-advisories/commit/08adf01e73341757f79f1d066cdfe080ceec7149

• https://www.cve.org/CVERecord?id=CVE-2023-6210 (done)
• https://www.mozilla.org/en-US/security/advisories/mfsa2023-49/ (should take a couple more minutes to refresh.)

Comment 25

[Godson Bastin]

Thank You!

Comment 26

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter