Closed Bug 1921733 (CVE-2024-10458) Opened 10 months ago Closed 9 months ago

Camera, Microphone, Geolocation etc permission takeover of trusted Top Origin Site through <embed> content, with no user interaction on Windows Firefox Nightly

Categories

(Core :: DOM: Security, defect)

defect

Tracking

()

VERIFIED FIXED
133 Branch
Tracking Status
firefox-esr115 132+ verified
firefox-esr128 132+ verified
firefox131 --- wontfix
firefox132 + verified
firefox133 + verified

People

(Reporter: proof131072, Assigned: farre)

References

Details

(5 keywords, Whiteboard: [client-bounty-form][domsecurity-active][adv-main132+][adv-esr128.4+][adv-esr115.17+])

Attachments

(5 files)

Imagine user visiting trusted legitimate webcam sites when all of a sudden your webcam is hijacked with full control allowing to spy on you.

Steps to reproduce:

  1. Go to https://legitimatewebcamsite.com/webcam and allow Camera access from legitimate webcam site.

  2. Go to https://legitimatewebcamsite.com/Evil_Webcam to confirm that Cross-Origin Evil site https://pwning.click/access_camera has a full camera control.

Flags: sec-bounty?

ISTM this was supposed to be fixed in bug 1755081 so perhaps this is a regression?

Group: firefox-core-security → dom-core-security
Component: Security → DOM: Security
Flags: needinfo?(fbraun)
Flags: needinfo?(afarre)
Product: Firefox → Core
Summary: Camera, Microphone, Geolocation etc permission takeover of trusted Top Origin Site through embedded ad banner in trusted legitimate site, with no user interaction on Windows Firefox Nightly → Camera, Microphone, Geolocation etc permission takeover of trusted Top Origin Site through <embed> content, with no user interaction on Windows Firefox Nightly
See Also: → 1595491

(In reply to :Gijs (he/him) from comment #1)

ISTM this was supposed to be fixed in bug 1755081 so perhaps this is a regression?

Doesn't seem like a regression. When I navigate to https://legitimatewebcamsite.com/Evil_Webcam/ with Firefox 92, 93 and 101 I still get the prompt even though there is no allow attribute on the iframe.

Edit: This is odd, there is even a test case for cross origin <embed>: https://searchfox.org/mozilla-central/rev/9fe73403523732f57cd82d30590ecc272fb0b165/dom/security/featurepolicy/test/mochitest/test_nested.html#56,58

See Also: → 1921818
See Also: → 1921847

@pbz How are those permissions handled? For the combination of top-level & embedded or something else?

My reading of https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy#iframes is that a site can pass on its permissions to iframes using allow. So, if a user grants the site a permission an iframe might have it but it's not clear to me what should happen if the site doesn't have the permission yet.

Flags: needinfo?(pbz)

Disclaimer: I'm not an expert on permissions policy.

Permissions are checked against / stored for the top level principal. We implement https://developer.mozilla.org/en-US/docs/Web/HTTP/Permissions_Policy
If no policy is specified that allows the frame to do the permission delegation to the top level we should not prompt to begin with. Here is an example page with different scenarios: https://joo.uber.space/frame-permissions.html You can see that the frame without permissions policy does not even trigger a prompt. The fact that it happens for <embed> seems like a bug.

Flags: needinfo?(pbz)

Nika was wondering if maybe frame and frameset had a similar kind of problem.

Checking if a policy is allowed isn't limited to iframes, as can be seen in https://w3c.github.io/webappsec-permissions-policy/#check-permissions-policy, in essence any kind of loaded document is governed by feature policies. But something is amiss, I've been looking into it and I think I'm making progress.

Assignee: nobody → afarre
Status: NEW → ASSIGNED
Flags: needinfo?(afarre)

Again this happened because <object> and <embed> are containers, but not treated so by Feature Policy. What was missing was a transfer of the feature policy info when an object load was upgraded to a document load, which is done automatically for <iframe> but needs special handling for <object> and <embed>.

Flags: needinfo?(dveditz)
Whiteboard: [client-bounty-form] → [client-bounty-form][domescurity-active]
Whiteboard: [client-bounty-form][domescurity-active] → [client-bounty-form][domsecurity-active]

Comment on attachment 9429645 [details]
Bug 1921733 - Update load info when object loads get upgraded. r=#dom-core!

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Since this happens when a site embeds a cross origin document using object/embed, this is what needs to happen. It means that not only must a seldom used element be the container element, the site must also embed an "evil" 3rd party.
  • 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: 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?: The patch is in seldom touched code, which might indicate that it could be applied as is.
  • How likely is this patch to cause regressions; how much testing does it need?: Shouldn't be more likely to cause regression than average.
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: Yes
Attachment #9429645 - Flags: sec-approval?

FYI, this grafts cleanly to everything except ESR115. It'll need a bit of rebasing there.

Thanks for checking! Attached a patch that contains the rebase + missing pieces. Not different to warrant a new review I think.

Flags: needinfo?(afarre) → needinfo?(ryanvm)

Comment on attachment 9429645 [details]
Bug 1921733 - Update load info when object loads get upgraded. r=#dom-core!

Approved to land and request uplift

Attachment #9429645 - Flags: sec-approval? → sec-approval+
Whiteboard: [client-bounty-form][domsecurity-active] → [client-bounty-form][domsecurity-active][reminder-test 2024-12-10]

(In reply to Andreas Farre [:farre] from comment #14)

Thanks for checking! Attached a patch that contains the rebase + missing pieces. Not different to warrant a new review I think.

Thanks for doing the rebase. Now that you've got sec-approval, please go ahead and Lando the patch and request Beta/ESR128/ESR115 on the respective patches.

Flags: needinfo?(ryanvm)

Comment on attachment 9429645 [details]
Bug 1921733 - Update load info when object loads get upgraded. r=#dom-core!

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Permission to use feature policy protected resources might leak to cross-origin containers.
  • Fix Landed on Version: 133
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Relatively small patch that concerns the use of <object>/<embed> which in turn are rarely used elements.

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Permission to use feature policy protected resources might leak to cross-origin containers.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Steps in bug description, tests will land later in https://bugzilla.mozilla.org/attachment.cgi?id=9429646.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Relatively small patch that concerns the use of <object>/<embed> which in turn are rarely used elements.
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9429645 - Flags: approval-mozilla-esr128?
Attachment #9429645 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9430772 [details]
WIP: Bug 1921733 - Update load info when object loads get upgraded.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Permission to use feature policy protected resources might leak to cross-origin containers.
  • Fix Landed on Version: 133
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Relatively small patch that concerns the use of <object>/<embed> which in turn are rarely used elements.

Note that this is a rebased version of the original patch from before Bug 1875822 landed. A slight rework, that doesn't change bahaviour was needed to finish the rebase. This hasn't been reviewed, if that is required please state this and I'll do that and re-request.

Attachment #9430772 - Flags: approval-mozilla-esr115?
Flags: needinfo?(afarre)
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/22662fcc2898 Update load info when object loads get upgraded. r=necko-reviewers,peterv
Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 133 Branch

Comment on attachment 9429645 [details]
Bug 1921733 - Update load info when object loads get upgraded. r=#dom-core!

Approved for 132.0b8.

Attachment #9429645 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [post-critsmash-triage]
QA Whiteboard: [post-critsmash-triage] → [post-critsmash-triage] [qa-triaged]

I confirmed 132.0b8 fixed XSLT bug 1921818 and spoofing bug 1921847 too for both <embed> and <object>, where bug 1921847 could be used for spoofing the request "Unknown origin" as a Top Origin site while it's not really from the Top Origin site, resulting to asking for "Unknown origin" permission for trusted Top Origin site.

bug 1921818 with XSLT allowed this to work from not just <embed> and <object> but from <iframe> border for cdpn.io contained in https://codepen.io which means <iframe> ad banner in any legitimate webcam site containing malicious camera takeover page with <embed> or <object> which is prepared from attacker's side could've taken over camera to live record and screenshot. Of course, Microphone record on legitimate voicechat site was possible too.

Flags: sec-bounty? → sec-bounty+

Comment on attachment 9429645 [details]
Bug 1921733 - Update load info when object loads get upgraded. r=#dom-core!

Approved for 128.4esr.

Attachment #9429645 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+

Comment on attachment 9430772 [details]
WIP: Bug 1921733 - Update load info when object loads get upgraded.

Approved for 115.17esr.

Attachment #9430772 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+

Reproduced the initial issue using Firefox 132.0b7, verified that using latest build of Nightly 133, Beta 132, 115esr and 128esr across platforms (Windows 11, macOS 13 and Ubuntu 22.04) the permission is not carried over the "Evil site".

Whiteboard: [client-bounty-form][domsecurity-active][reminder-test 2024-12-10] → [client-bounty-form][domsecurity-active][reminder-test 2024-12-10][adv-main132+][adv-esr128.4+][adv-esr115.17+]

(In reply to James Lee from comment #24)

I confirmed 132.0b8 fixed XSLT bug 1921818 and spoofing bug 1921847 too for both <embed> and <object>, where bug 1921847 could be used for spoofing the request "Unknown origin" as a Top Origin site while it's not really from the Top Origin site, resulting to asking for "Unknown origin" permission for trusted Top Origin site.

bug 1921818 with XSLT allowed this to work from not just <embed> and <object> but from <iframe> border for cdpn.io contained in https://codepen.io which means <iframe> ad banner in any legitimate webcam site containing malicious camera takeover page with <embed> or <object> which is prepared from attacker's side could've taken over camera to live record and screenshot. Of course, Microphone record on legitimate voicechat site was possible too.

Based on this, should we close out some of the referenced bugs, or is there more to be done there?

Alias: CVE-2024-10458

(In reply to :Gijs (he/him) from comment #1)

ISTM this was supposed to be fixed in bug 1755081 so perhaps this is a regression?

I haven't looked into the code and either of the bugs. If you don't mind, given you looked into it just very recently by way of fixing the bug here, maybe Andreas Farre can answer that question. I'd also be curious why the test from bug 1755081 did not cover this and whether our new tests are exhaustive over all sorts of embedding scenarios (embed, object, iframe, frame, popup, popup from cross-origin/sandboxed content) for (same-origin, cross-origin, sandboxed origin)

Flags: needinfo?(fbraun)

In bug 1755081 we had the case where we had and embed/object nested in an iframe, whereas this concerns an embed/object in an auxiliary top-level browsing context. In bug 1755081 we will correctly propagate the load info since the cross origin iframe starts the navigation, and here the feature policy is already set on that container and the embed inherits in in the same process.

In this bug the process switch happens in the embed/object, and we need to set the feature policy on that container, something we can only do when we have a browsing context. This is the reason for why we need to wait for the document load listener upgrade.

If you by "new tests" you mean the test I have in patch D224957, then it most definitely doesn't cover all possible combinations of containers and policies. It covers the one case of process switching an embed/object element in a top-level document, which is the root cause of this bug.

It would be good to have the test suite be more extensive in what it tests, especially since feature policy didn't support embed/object from the beginning.

Also, since this has been uplifted to esr115/128 and 132 is release now, it should be ok for me to go ahead and land the test?

Flags: needinfo?(afarre) → needinfo?(fbraun)
Blocks: 1921818

Well, 132 was just released last week. We usually wait a couple of weeks to ensure everyone had the chance to take the update. I'd like us to wait for something mid/late November, preferably.

Flags: needinfo?(fbraun)

(In reply to Frederik Braun [:freddy] from comment #34)

Well, 132 was just released last week. We usually wait a couple of weeks to ensure everyone had the chance to take the update. I'd like us to wait for something mid/late November, preferably.

Excellent! Adding a ni to myself to keep this on my radar. I'm on PTO 25-28 November, I'll land this as soon as I'm back.

Flags: needinfo?(afarre)
Duplicate of this bug: 1921818
Blocks: 1921847
See Also: 1921847

a month ago, tjr placed a reminder on the bug using the whiteboard tag [reminder-test 2024-12-10] .

farre, please refer to the original comment to better understand the reason for the reminder.

Flags: needinfo?(afarre)
Whiteboard: [client-bounty-form][domsecurity-active][reminder-test 2024-12-10][adv-main132+][adv-esr128.4+][adv-esr115.17+] → [client-bounty-form][domsecurity-active][adv-main132+][adv-esr128.4+][adv-esr115.17+]
Flags: needinfo?(afarre)
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: