1305232 - CTP doorhanger/notification uses toplevel domain/principal instead of that of the iframe when asking the user to allow plugins

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

1. Go to https://shhnjktest.blogspot.ae/2016/09/fdf-test.html with Firefox 49.0.1
2. Even though site requesting Acrobat reader is https://shhnjk.com, Firefox says "Allow https://shhnjktest.blogspot.ae to run Adobe Acrobat?"


Actual results:

Firefox does not care about who requested Acrobat and just mentions top origin of document in alert. This behavior can be used by malicious advertisement to deliver Acrobat specific exploit using trusted origin by user. 


Expected results:

Alert should include site origin who actually requested Acrobat *OR* include origin of PDF, FDF, or XDFD which will be loaded using Acrobat.

Comment 1

[:Gijs (back August 25; he/him)]

I believe the choice of what to display here is intentional, well-understood, and not a security risk, but I defer to Benjamin to confirm and have this opened up. In particular, bug 853855 already provides some of the rationale about why we do what we do.

(In reply to s.h.h.n.j.k from comment #0)
> This behavior can be used by malicious
> advertisement to deliver Acrobat specific exploit using trusted origin by
> user. 

I think you're very optimistic about the type of isolation that sites use for their advertising. Many/most of them use pretty direct script inclusion on domains they control to insert the ads, so there's no way to make that distinction anyway. That is, if you allow <plugin> for foo.com, you're implicitly allowing it for all the ads on foo.com, because the ads will often run on foo.com. For instance, Google provides you with:

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

and so you'll just run Google's code directly on foo.com. If the script was hijacked and inserted a pdf exploit, it'd still be running on foo.com. The ad scripts themselves might create/insert iframes, but from a threat analysis perspective, if you assume the advertiser is compromised that doesn't make a difference - there's no guarantee what the script does and nothing to protect foo.com from it.

Comment 2

[Benjamin Smedberg]

This behavior is by design. We have explicitly chosen to make the Flash-allow decision based on the toplevel domain and not the subdomain. There are multiple related reasons for this design:

* a page with multiple domains would have very confusing/unusable UI in the permission dialog
* we don't want allowing advertising Flash on one site to affect other sites
* Thus, the way we store and activate the underlying permissions is by toplevel site, not by subdomain

So the UI matches the underlying permission model being provided here, and we're going to keep that model. Resolving this bug WONTFIX.