1861825 - Permission prompts for webrtc from blobs generated by file:// documents should say "this file" not "unknown origin"

Status: RESOLVED DUPLICATE of bug 801066

(Core :: WebRTC, defect)

Description

[Hafiizh]

Attachment: bandicam 2023-10-28 22-34-02-822.mp4

i found vulnerabilty where iframe with https protocol can delegate the permission to blob:null (local file) on top level origin. normaly the permission delegation on top level origin must https protocol

steps to reproduce:

1. download and open blob1_new.html
2. click on click me button
3. click camera on iframe with https protocol

Comment 1

[Hafiizh]

Attachment: blob1_new.html

Comment 2

[Daniel Veditz [:dveditz]]

It's the other way around: the top level origin (in this case a blob:) delegates permission to the iframe. Without the "allow" attribute the iframe would not be able to request permissions. With it, the iframe inherits the permissions delegated from the top document. If the permissions had already been granted the framed content could simply use the feature, but in this case the requests from the framed content trigger the permission request in the parent. The permission is then granted to the parent. Because of the "allow" delegation the framed content can then use it.

In a normal -web- page this isn't spoofy at all, as you can see if you load the testcase from the bugzilla attachment. The attachment testcase uses the domain https://bug1861825.bmoattachments.org, so it creates same-origin blobs like blob:https://1861825.bmoattachments.org/... and the permission prompts correctly ask about granting to the parent domain bug1861825.bmoattachments.org

In your movie, and mentioned in comment 0, you're using a local file which has an "opaque" origin. In the blob url it shows up as "blob:null", but the permission prompts saying "from an Unknown origin" would happen if you loaded the pop-up window as a local file. You can try this by saving the following in a local fle:

<title>www.paypal.com</title>
<h1>POC</h1>
<iframe src='https://permission.site' width='700px' height='700px' allow='fullscreen; camera; display-capture; encrypted-media; fullscreen; geolocation; microphone; payment; usb; vr; midi; serial; hid; clipboard-write; clipboard-read;'>
</iframe>

In Chrome the prompts from a local file outer origin say "This file wants to" (a couple say "file:/// wants to"). In this testcase, though, the blob:null popup says "Not secure" in the address bar and most permission requests are denied. This appears to be because of the "Not secure" designation; the clipboard read permission shows a prompt with Chrome's usual (for file:///) "this file wants to" text.

I'm not sure what the anchor text is supposed to do. Looks like an attempt to spoof "www.paypal.com" but it's pushed way out of the field. The <title> "www.paypal.com" shows up in the tab title which is I suppose more effective as a spoof if people are confused by the address bar (though of course the <title> can never ever be trusted).

Observations:

• "from an unknown origin" for permission prompts from file:/// is kind of wrong: we DO know the origin
• that said, I don't find it more spoofy than Chrome's "this file wants to". Either way it's not Paypal!!
• Chrome is wrong to say a blob: created by a file:/// is "Not Secure"
• users are unfamiliar with blob: urls so it's always potentially spoofy. Might not be terrible to change the spec to say "top-level blob: urls can't delegate permissions".
• failing that, maybe restrict delegation to blob:https: urls. That's sort of where Chrome is in practice, but I think that's an accidental side-effect of the "Not Secure" designation since they still allow some permissions to delegate.

"Save this file, open it, and let me try to trick you" is not that effective a spoofing vector. There technically isn't a spoof here since the permission prompts clearly are not granting the permission to whatever upstanding trusted site you're trying to convince the user it is. I'm not sure we need to keep this one hidden.

Comment 3

[Daniel Veditz [:dveditz]]

Looks like the "Core" product is for the implementation of various permissions themselves, but Firefox::Security was an OK place to start for the prompt UX.

Comment 4

[Daniel Veditz [:dveditz]]

Maybe when we get the point that we're going to ask the user to grant something to "An Unknown origin" we should just not show the prompt and deny the privilege. But developers are going to want to grant permissions to local files they're developing in so we need to allow that much and should adopt something like Chrome's "this file" type prompt.

There is absolutely no bug here in the delegating part: the Permission Policy spec is behaving as designed.

Comment 5

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

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

For more information, please visit BugBot documentation.

Comment 6

[:Gijs (he/him)]

Given the origin associated with the blob is null, I'm not sure we can easily determine what is going on here in the site permissions code.

There's some previous discussion in bug 1366357. We actually show "local file" for geolocation prompts. I don't know why we don't for webrtc. I couldn't get any other items on permissions.site to produce prompts, other than the protocol handler one which only tells the user the target site (which is correct behaviour). IOW, I think the only thing that needs to be fixed here is the webrtc (microphone, camera, screen share etc.) items. Over to WebRTC as hopefully :jib still remembers the context here as to why we didn't align webrtc with geolocation and the other prompts. (Maybe it's easier to do the right thing now with precursorPrincipals and such? I don't know.)

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This is just bug 801066 and the blob and iframe are red herrings (a local patch confirms blob urls are fine with that fixed, but a proper patch will require a bit more for proper translation).

As to why webrtc permission code isn't aligned with that of geolocation etc, it's because of its complicated permission needs, and lack of resources.

• Chrome is wrong to say a blob: created by a file:/// is "Not Secure"

Agreed, based on https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy

This is really the only thing I see that makes Firefox stand out here. Both browsers allow camera and microphone access from local files. That local file navigating to a blob of its creation shouldn't change any security properties (even if pasted elsewhere it can't survive its opener closing).

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: The anchor text seems aimed at Chrome's "Not secure" dropdown

I'm not sure what the anchor text is supposed to do. Looks like an attempt to spoof "www.paypal.com" but it's pushed way out of the field.

Ironically it seems aimed at confusing Chrome users who read the "Not secure" warning.

Hopefully we're not affected?