1551886 - (CVE-2021-38491) Opaque documents aren't considered in the mixed content blocker

Status: VERIFIED FIXED

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

Description

[Jonathan Kingston [:jkt] he/him]

I raised Bug 1519406 about the mixed content blocker getting a requestingLocation that is a NullPrincipal. This principal doesn't appear to be handled correctly.

However it also seems that the way we evaluate if we should block is based only on the parent context: https://searchfox.org/mozilla-central/rev/116bd975c30746ddefc3d20e6947d1871469354f/dom/security/nsMixedContentBlocker.cpp#733-751

So I was able to replicate the unblocked resources:

1. Go to https://example.com
2. Use inspector to inject <iframe src="data:text/html,<iframe src='http://localhost'></iframe>"></iframe> or <iframe src="data:text/html,<iframe src='http://example.com'></iframe>"></iframe>

In Firefox the inner frame loads and Chrome blocks this.

Comment 1

[:Gijs (he/him)]

This sounds suspiciously like what Christoph was saying in https://bugzilla.mozilla.org/show_bug.cgi?id=1550414#c5 . Christoph, is this also fixed when we move CSP to Client?

Comment 2

[Jonathan Kingston [:jkt] he/him]

I doubt it quite a lot as the MCB doesn't use CSP (besides for the opt in case by CSP). The code is in the evaluation of those lines and not traversing docshells / behaving in a similar way.

Christoph you haven't changed anything other than CSP right?

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jonathan Kingston [:jkt] from comment #2)

Christoph you haven't changed anything other than CSP right?

The problems described within this bug are orthogonal to my changes to the CSP code. For this bug we somehow need to inspect the embedding context in case the subresource loaded was triggered by an opaque origin. In general we need a better abstract mechanism for things that need to be inherited into opaque contexts. It seems we are fighting the same problems over and over.

FWIW, another testcase would be using a srcdoc iframe which I am pretty sure also doesn't work correctly.

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

Just chatted with Dan and we think this is actually a sec-moderate. In terms of how we could fix that, we should check if we can somehow propagate the isSecureContext flag. In other words, if a secure context creates an opage origin iframe (e.g. data: iframe) then we can make a decision within the MixedContentBlocker based on that.

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

Probably some wpt-tests around opaque origins would be beneficial.

Comment 6

[Jonathan Kingston [:jkt] he/him]

<iframe src="data:text/html,<script>console.log(window.isSecureContext)</script>"></iframe> I think we also agreed that this should console true when it currently doesn't. This would potentially make the mcb only have to check parent.isSecureContext rather than the propagated ancestor is secure solution.

Comment 7

[Neha Kochar [:neha]]

Christoph, please review this sec bug and figure out next steps?

Comment 8

[Christoph Kerschbaumer [:ckerschb]]

Doing either Bug 1660452 or even better Bug 1715167 will fix that problem. We should really tackle Bug 1715167 soon - marking dependency to Bug 1715167 so we keep the reference.

Comment 9

[Niklas]

Attachment: Bug 1551886: Check the parent scheme for NullPrincipals via the precusor principal. r=ckerschb

Comment 11

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

Backed out for WPT unexpected passes in worker-classic-data.http-rp/opt-in/fetch.https.html

https://hg.mozilla.org/integration/autoland/rev/f9a0759c1872473f30fa0221be70585f4baaa2e6

It had landed as https://hg.mozilla.org/integration/autoland/rev/ec131014f7fda0a016a8b0ea085e9c4edaff9b8e

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=ec131014f7fda0a016a8b0ea085e9c4edaff9b8e&selectedTaskRun=Iz3EuQ-cSHqb-iQYkr9qPA.0
Failure log: https://treeherder.mozilla.org/logviewer?job_id=345905358&repo=autoland

16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to cross-http origin and keep-scheme redirection from https context. - expected FAIL
8244	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to cross-http origin and no-redirect redirection from https context. - expected FAIL
8247	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to cross-http origin and swap-scheme redirection from https context. - expected FAIL
8250	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to cross-https origin and swap-scheme redirection from https context. - expected FAIL
8253	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to same-http origin and keep-scheme redirection from https context. - expected FAIL
8256	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to same-http origin and no-redirect redirection from https context. - expected FAIL
8259	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to same-http origin and swap-scheme redirection from https context. - expected FAIL
8262	16:06:57 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to same-https origin and swap-scheme redirection from https context. - expected FAIL
8398	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to cross-http origin and keep-scheme redirection from https context. - expected FAIL
8401	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to cross-http origin and no-redirect redirection from https context. - expected FAIL
8404	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to cross-http origin and swap-scheme redirection from https context. - expected FAIL
8407	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to cross-https origin and swap-scheme redirection from https context. - expected FAIL
8410	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to same-http origin and keep-scheme redirection from https context. - expected FAIL
8413	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to same-http origin and no-redirect redirection from https context. - expected FAIL
8416	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to same-http origin and swap-scheme redirection from https context. - expected FAIL
8419	16:07:04 INFO - TEST-UNEXPECTED-PASS | /mixed-content/gen/worker-classic-data.http-rp/opt-in/xhr.https.html | Mixed-Content: Expects blocked for xhr to same-https origin and swap-scheme redirection from https context. - expected FAIL

Comment 12

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

Landed: https://hg.mozilla.org/integration/autoland/rev/27644fd8810b665cb0bcfc9f5f6e93622e64f5e5

Backed out for wpt failures on /mixed-content/

• backout: https://hg.mozilla.org/integration/autoland/rev/ba3142d0ddc7ff02fb91325543ab72bed7c97faa

• push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=27644fd8810b665cb0bcfc9f5f6e93622e64f5e5

• failure logs:

  • TEST-UNEXPECTED-PASS | /mixed-content/gen/sharedworker-classic-data.meta/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to cross-http origin and no-redirect redirection from https context. - expected FAIL
  • TEST-UNEXPECTED-PASS | /mixed-content/gen/sharedworker-classic-data.http-rp/opt-in/fetch.https.html | Mixed-Content: Expects blocked for fetch to cross-http origin and keep-scheme redirection from https context. - expected FAIL

Comment 13

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

Check the parent scheme for NullPrincipals via the precusor principal. r=ckerschb
https://hg.mozilla.org/integration/autoland/rev/1fa3099b6c3919de131b7161625519aa4201b322
https://hg.mozilla.org/mozilla-central/rev/1fa3099b6c39

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Is this something we need to consider backporting to Beta/ESR78?

Comment 15

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)

Is this something we need to consider backporting to Beta/ESR78?

The short answer is no, no need to do that.

The longer answer is:

• Our implementation of the mixed content blocker has not been able to correctly detect this corner case almost since it's inception.
• Additionally to uplifting this patch we would have to uplift all the Principal changes from Bug 1715167 which are (in my opinion) more likely to cause some other side effect when uplifted than the benefit of having this corner case fixed.

Thanks for checking though!

Comment 16

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello!
Tried to verify the issue but this is what I came across on Windows 10x64 and I don't know if this is expected:

1. Using <iframe src="data:text/html,<iframe src='http://example.com'></iframe>"></iframe> -> the second iFrame is blocked on Chrome, Firefox 92.0b9 and is not blocked on affected Firefox 91.0a (20210707215219).
2. Using <iframe src="data:text/html,<iframe src='http://localhost'></iframe>"></iframe> -> the second iFrame does not get blocked on Chrome, Firefox 92.0b9 and Firefox 91.0a (affected build) Is this expected? Thank you in advance!

Comment 17

[Niklas]

Hi, thanks for verifying!

This is indeed expected. Requests made to localhost are always assumed to be delivered securely and are therefore exempt from mixed content blocking.

Comment 18

[Alexandru Trif, Desktop Test Engineering [:atrif]]

(In reply to Niklas from comment #17)

Hi, thanks for verifying!

This is indeed expected. Requests made to localhost are always assumed to be delivered securely and are therefore exempt from mixed content blocking.

Thank you! Closing this as verified based on the above.

Comment 19

[Frederik Braun [:freddy]]

Attachment: advisory.txt