Closed Bug 1808979 (CVE-2025-8038) Opened 3 years ago Closed 10 months ago

CSP `frame-src <host-source>;` lets iframe change location on same origin

Categories

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

Product:
Core
Component:
DOM: Security
Version:
Firefox 108
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
141 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- wontfix
firefox-esr128 --- wontfix
firefox-esr140 141+ fixed
firefox139 --- wontfix
firefox140 --- wontfix
firefox141 + fixed

People

(Reporter: accounts, Assigned: tschuster)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-mitigation-bypass, reporter-external, sec-low, Whiteboard: [domsecurity-active][adv-main141+][adv-ESR140.1+])

Attachments

(3 files)

Bug 1808979 - Disable security.csp.truncate_blocked_uri_for_frame_navigations by default. r?freddyb,dveditz
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-esr140+
Details | Review
Bug 1808979 - WPT for frame-src path matching after replacing the URL. r?freddyb,dveditz
48 bytes, text/x-phabricator-request
Details | Review
advisory.txt
141 bytes, text/plain
Details

Steps to reproduce:

I tried to restrict an iframe from changing its location by enforcing a CSP frame-src <URI to iframe>;.

Minimal Code example

parent.html:

<!DOCTYPE html>
<html>
    <head>
        <meta
            http-equiv="content-security-policy"
            content="frame-src http://localhost:5501/target.html; "
        >
    </head>
    <body>
        <div>
            I'm hosting an iframe.
        </div>
        <iframe
            src="target.html"
        ></iframe>
    </body>
</html>

iframe.html:

<!DOCTYPE html>
<html>
    <head></head>
    <body>
        I'm an iframe. Look at <a href="third-site.html">third site.</a>
    </body>
</html>

third-site.html:

<!DOCTYPE html>
<html>
    <head></head>
    <body>Some arbitrary content</body>
</html>

This example uses origin http://127.0.0.1:5501, I tested on my server (https, proper domain name) as well, same behaviour.

I tested on an arch linux and an ubuntu.

Actual results:

I can change the location clicking a link <a href="<same-origin>/different-document.html"> or using window.location = "<same-origin>/different-document.html".

I was not redirected to URI https://example.net/ testing the same behaviour.
This behaviour did neither occur in chromium.

Expected results:

The iframe should not have changed location.

Since it's a CSP issue, I'll tick the security check box just to be sure.

Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM: Security
Product: Firefox → Core

I am going to investigate.

Assignee: nobody → tschuster
Severity: -- → S3
Priority: -- → P3
Whiteboard: [domsecurity-active]

So this is caused by us treating frame navigations as redirects and in case of redirects we ignore the path of a host src when matching.

I think bug 1542194 also motivates why ignoring the path is useful, otherwise by blocking a very specific URL the embedding page could detect what is being loaded in the cross-origin frame.

Flags: needinfo?(dveditz)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Depending on what we end up doing in the other bug you're working on maybe we'll have a better idea of what we want to do here. For now treating all navigation in a frame as a "redirect" for CSP purposes solves problems like bug 1542194. That problem is about what information the framing page can glean so we might be able apply restrictions more strictly if we can stop those leaks. That would mean not only to stop reporting any CSP violations to the parent page after the initial page load, we'd have to suppress the onload/error event handlers of cross-origin iframes, or make all navigations report onload whether they succeeded or not--which I bet would be hard to do without missing any cases. And if we did any such thing we'd want it to be consistent across browsers.

Flags: needinfo?(dveditz)
Keywords: sec-other
See Also: → CVE-2021-23969, CVE-2023-25728
Whiteboard: [domsecurity-active] → [keep hidden while see-also bugs are][domsecurity-active]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons

Keywords: reporter-external

Can you take a look if this bugs needs to be kept around with the recent changes in CSP?

(Also setting sec-bounty to ? to indicate that the reporter would like this to be considered for a bounty in case this needs its own fix and in case this gets a high enough severity rating)

Flags: sec-bounty?
Flags: needinfo?(tschuster)

This code hasn't changed at all. However this is quite similar to bug 1891466 ("CSP frame-ancestors incorrectly ignores the path component") and thus similarly rewriting our source matching algorithm (bug 1899512) should fix this.

Flags: needinfo?(tschuster)
Depends on: 1899512
Blocks: CSP

(In reply to Tom Schuster (MoCo) from comment #7)

thus similarly rewriting our source matching algorithm (bug 1899512) should fix this.

Doesn't that re-expose us to bug 1542194 (CVE-2021-23969)?

Flags: needinfo?(tschuster)

That patch seems to just have changed which URI is being reported, so I don't think we would even change that.

Flags: needinfo?(tschuster)
See Also: → 1901418

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: tschuster → nobody
Assignee: nobody → tschuster
Flags: sec-bounty? → sec-bounty-
Keywords: keep-hidden
Whiteboard: [keep hidden while see-also bugs are][domsecurity-active] → [domsecurity-active]
Duplicate of this bug: 1969154

I think we can fix this by just disabling security.csp.truncate_blocked_uri_for_frame_navigations. Since bug 1790345 we strip all cross-origin URIs when reporting frame-src or object-src violations. This matches what Chrome and Safari are doing and was discussed as an alternative fix already in bug 1542194.

No longer depends on: 1899512
See Also: → CVE-2025-8031
Pushed by tschuster@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/bbc2fc0457eb https://hg.mozilla.org/integration/autoland/rev/d6d7f3da0b06 Disable security.csp.truncate_blocked_uri_for_frame_navigations by default. r=freddyb

I think sec-other is not the best rating. Let's re-rate this.

Keywords: sec-other

https://hg.mozilla.org/mozilla-central/rev/f24014065b16
https://hg.mozilla.org/mozilla-central/rev/d6d7f3da0b06

Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 10 months ago
status-firefox141: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 141 Branch

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

For more information, please visit BugBot documentation.

Flags: needinfo?(tschuster)
status-firefox140: affected → wontfix
Flags: needinfo?(tschuster)
Keywords: sec-low

Did you want to nominate this for ESR140 uplift?

status-firefox-esr115: affected → wontfix
status-firefox-esr128: affected → wontfix
tracking-firefox141: --- → +
tracking-firefox-esr140: --- → 141+
Flags: needinfo?(tschuster)
QA Whiteboard: [sec] [qa-triage-done-c142/b141]
Flags: qe-verify-

Comment on attachment 9494031 [details]
Bug 1808979 - Disable security.csp.truncate_blocked_uri_for_frame_navigations by default. r?freddyb,dveditz

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: A Content-Security-Policy that restricts which frames are allowed to load would not correctly restrict the path on an allowed domain + path.
  • User impact if declined: Possible XSS or other website attacks.
  • Fix Landed on Version: 141
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Pref change
Flags: needinfo?(tschuster)
Attachment #9494031 - Flags: approval-mozilla-esr140?
Attachment #9494031 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
Whiteboard: [domsecurity-active] → [domsecurity-active][adv-main141+]
Whiteboard: [domsecurity-active][adv-main141+] → [domsecurity-active][adv-main141+][adv-ESR140.1+]
Alias: CVE-2025-8038
Flags: sec-bounty-hof+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: