Closed Bug 1921847 Opened 2 years ago Closed 1 year ago

Embedded HTML documents could request permissions to Top Origin which could lead to spoof attacks on Windows Firefox Nightly

Categories

(Core :: DOM: Security, defect)

defect

Tracking

()

RESOLVED FIXED
133 Branch
Tracking Status
firefox-esr115 --- fixed
firefox-esr128 --- fixed
firefox132 --- fixed
firefox133 --- fixed

People

(Reporter: proof131072, Assigned: farre)

References

Details

(Keywords: reporter-external, sec-other, testcase-wanted, Whiteboard: [client-bounty-form][domsecurity-active][adv-main132-])

Attachments

(2 files)

Steps to reproduce:

Go to https://codepen.io and follow the step on attached demo video.

We could to prevent permission requests from embedded HTML documents to Top Origin to avoid spoofing attacks.

Assuming https://codepen.io as a legitimate voicechat site in this example, we're getting Microphone permission request from legitimate voicechat site without the real attack site origin that looks like it's actually from the trusted legitimate voicechat site itself.

Flags: sec-bounty?

Kind of feels like this is a different manifestation of the same underlying issue as bug 1921733 (eg it depends on whether the top level page has the permission first vs top level page doesn't have it and then the child requests it), but I'm not familiar with this code so that might be wrong.

Group: firefox-core-security → core-security
Component: Security → DOM: Security
Product: Firefox → Core
See Also: → CVE-2024-10458
Group: core-security → dom-core-security

If this had a same behaviour when the top level page has the permission first, I'd agree with that but as you can check from the demo video, we actually already did allow the permission but this is a separate permission request with no origin asking for permission from top level page (two different mic permission icons there).

Okay, thanks. This is why it would be better if you wrote down the specific steps in the video and talked about why you thought they were relevant rather than just referring us to the video.

Right, my bad, this could actually end up as a duplicate for different reason anyways, but behaviourly it's not the same afaict.

Actually the steps are included in bug 1921818 since I explained the difference between testing with embedded HTML vs XSLT

When you test this issue, please paste this in JS Coding part on the right to test after allowing microphone permission.

        navigator.mediaDevices.getUserMedia(
          {audio: true}).then(
            
        ) :
        navigator.getUserMedia(
          {audio: true},
        
        );

And then we could test with embedded https://pwning.geniuscoolcat.com/Normal_HTML_Mic.html to reproduce this issue.

This issue occurs with Microphone and Camera permission but not with Location permission, as it'll reveal the correct attacker's origin unlike previous issues, by the way.

Attached video Only_Camera_and_Mic.mp4 —

As I mentioned, this doesn't work for Geolocation permission unlike previous 2 issues but ideally it'd be nice to prevent cross-origin permission requests entirely.

Actually the steps are included in bug 1921818 since I explained the difference between testing with embedded HTML vs XSLT

So this is a duplicate then? Are there different steps for this bug?

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

I explained this behaviour too in that report because I wanted to compare the clear difference for just HTML "Normal_HTML_Mic.html" which causes that spoofing issue with the Top Origin site asking e.g. "allow codepen.io to give Unknown origin access to your microphone" as we can confirm from the attached demo video https://bugzilla.mozilla.org/attachment.cgi?id=9428139 that works for Camera and Mic but not for Geolocation in this report vs XSLT "XSLT_Mic.xml" taking over Top Origin Camera, Mic, Geolocation etc. So that XSLT one is actually only step 3 and this is a different "spoofing" issue.

Step to reproduce:

  1. Go to https://codepen.io and paste following code on JS coding on the right to allow Microphone access from https://codepen.io which we're assumming it as a legitimate voicechat site in this example.
        navigator.mediaDevices.getUserMedia(
          {audio: true}).then(
            
        ) :
        navigator.getUserMedia(
          {audio: true},
        
        );
  1. Check Firefox recognises embedded https://pwning.geniuscoolcat.com/Normal_HTML_Mic.html as an "Unknown origin" with the Top Origin https://codepen.io which could be used for permission spoofing attack.

As I mentioned above, they're not the same as we can confirm by testing this spoof issue alone, but it seems that possibly this behaviour could disappear by the fix.

Flags: needinfo?(proof131072)
Depends on: 1921818
Keywords: sec-other

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(fbraun)
Severity: -- → S3
Flags: needinfo?(fbraun)

This should be resolved with bug 1921733, right?

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Flags: sec-bounty? → sec-bounty-
Assignee: nobody → afarre
Group: dom-core-security → core-security-release
Depends on: CVE-2024-10458
No longer depends on: 1921818
See Also: CVE-2024-10458 →
Target Milestone: --- → 133 Branch
Has STR: --- → yes
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify+
Group: core-security-release
Whiteboard: [client-bounty-form][domsecurity-active] → [client-bounty-form][domsecurity-active][adv-main132-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: