New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner:
Email to this user bounced
Closed: Apr 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Security
M-5

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Plugins are not always blocked by content settings
Project Member Reported by darin@chromium.org, Mar 29 2010 Back to list
Plugins are not always blocked by content settings

Observed in 5.0.365.0 (Developer Build 42941)

Repro steps:
1- Modify content settings to block all plugins
2- Load test case
3- Click button
4- Notice that the plugin loads and can be played

The bug is likely related to the fact that we only send down the blocked 
content settings in response to a top-level navigation.  In this example, 
there is no top-level navigation since the newly opened window is to 
about:blank.
 
test_plugin_in_new_window.html
267 bytes View Download
We should ensure that any fix here is also applied to the zoom settings.  I think Ben 
was complaining that there are some weird and buggy corners of zoom, this might explain 
that?
Comment 2 by jsc...@chromium.org, Mar 30 2010
Labels: Restrict-View-SecurityTeam
Comment 3 by jsc...@chromium.org, Mar 30 2010
Labels: Security
What makes this a security bug?  That it weakens user abilities to temporarily disable 
all plugins to avoid Flash holes?  That seems like a thin justification...
This is a horrific security bug!!!
I use this feature to protect myself from Flash vulnerabilities. The only sites I let 
load plugins are pretty much youtube.com, hulu.com.
If evil.com can load plugins without my permission, that's not good.

(Ok, I admit this isn't horrific overall because most users don't protect themselves 
from Flash in the way I do. However, for advanced users who care about security -- 
small subset that they are -- this is not good).

Can we get it fixed ASAP?
Status: Assigned
looking into this...
Honestly I think Darin should look at this, as he walked me through designing the 
original system, and this stuff is tricky.
assigning Darin as owner.
Labels: Mstone-5
Status: Available
Darin and I chatted about this.

The key here is to realize that the newly-created window doesn't have a host, and 
thus no host-based settings could apply to it.  And the only way for it to get a host 
is to navigate, at which time we'll pass the right setting for the new host.

Therefore, the only settings that can apply are the global defaults.  That suggests 
the fix: when the renderer wants to create a new view, it sends an IPC to the 
browser; at that time, we should pass down the default settings so the renderer can 
apply them to the new view.  We can use our existing IPC for this.

This should be a small fix so we can merge it to the branch even after the feature 
freeze, but if anyone wants to do it now they're welcome.
Peter / Darin, thanks for your comments.
I just cc:ed you both on http://code.google.com/p/chromium/issues/detail?id=17655 -- 
does that sound same like the same possible root cause?
Here's what I sent to Peter from my phone:

"I need to look at the code, but we might want to use
frame->document->securityOrigin->host instead of frame->document->url->host.  That
should cover these about:blank cases better."
@10: Doesn't sound the same.
@11: What is the practical difference?
@12: The practical difference is that these about:blank pages will have the proper
host (the host of the page that created the window).  That's better than using the
default, which could let a site bypass the user's preferences.
Hmmmmmmmmm

It's non-obvious to me whether, as a user, I would want this page to obey my setting 
for the site that spawned it or to obey the setting for my global default.

Is the security origin host the same as the url host in all cases where the url host is 
something valid?  i.e. is this the only case that that change would affect?
I don't think the average user as any concept of about:blank, much less that
about:blank can be made to contain a non-blank page.  In fact, I bet most browser
developers don't even understand that.

If you want to make security decisions based on the host, you should use the host
from securityOrigin.  It's entire purpose in life is to get edge cases like this bug
correct.
Remember, I don't consider this a security decision as much as a UI decision :)

I agree users don't understand about:blank, but when the address bar says "about:blank"  
(as it does here), it doesn't look to me as a user like this page is on foo.com (or 
whoever opens it).  So I think I'd expect my global setting to apply.
Blocking plugins is a security feature.  One of the use cases is blocking Flash zero
days.  Of course, you need a global deny / white list for that use case.
Precisely, and in that use case, this popup would not be allowed to show a plugin.  So, no security worry.
I'm not sure why we're having this argument.  The about:blank context is already
complex.  If we special case the properties of the context in this case, we're going
to make our lives harder.  Instead, we should use the general-purpose code that we
use in the other cases.
What on earth are you talking about?  We're not special-casing anything.  The problem 
here is that no navigation occurs, so no settings get sent down.  About anything.  That 
includes both the default settings, and the settings for the security origin.  We have 
to patch to give the renderer some settings to use for this case.  The only debate here 
is _which_ set of settings applies; there is absolutely no difference in the scope of 
the patch.  I am claiming that passing the default settings makes more sense from a 
user's point of view than the settings for the security origin.
@abarth, @pkasting: I can see both points of view. From a security angle, using the 
default settings would be fine because the only secure way to use this feature is in 
"default deny" mode.
Actually, that would break permitted usages of plugins in window.open()'ed windows for 
"default deny" users. Therefore, Adam's proposal to use the domain from the 
SecurityOrigin is a must IMHO.
My point is that there is no permitted usage of a plugin in a window.open()'ed, no-URL, 
unnavigated window for users whose settings are "default deny".
To be clearer: If A window.open()s url B, plugin settings for B are applied, not A.  
The opener is irrelevant.  Keeping that consistent for all B (including the empty URL) 
is the right thing to do.
@pkasting: ok, sure. You're fine with breaking legitimate sites which pop-up a same-
origin window to run a plugin in?
If you pop up a same-origin window, things already work fine.
@pkasting: look at the test case. window.open() with an empty string. That's 
considered a same-origin window by the same origin policy. Sites could be relying on 
that fact. There may be other corner-cases with <iframe></iframe>.
Oh, I thought you were referring to it having a URL with the same origin.

Yes, I am fine with popups for windows whose visible URL is "about:blank" to be subject 
to your global default setting irrespective of the site that opened.  I'm not sure how 
many different ways I can say that this makes more sense to a user.
Here's a real-life use case for you:

1) Default-deny JavaScript.
2) Allow JavaScript for Gmail.
3) Click a link in Gmail.

To follow the link, Gmail opens a window to about:blank and then injects a bunch of
junk into that window to navigate it to the web site you want.  It's possible that
they only inject HTML, but there's no reason they wouldn't inject JavaScript.  You
want that JavaScript to run, but with the policy you outline, it's broken.

Aaaarrrggghhhhhhhhh

Things suck either way.  Fine.  I concede.
Status: Started
Status: Assigned
I've dug into it and it's pretty hairy. Problems:

1) The RenderView::AllowContentType() method is not fail safe. If it never received 
any specific content setting, then CONTENT_SETTING_DEFAULT is used even for users 
whose default is to block everything.

2) Fixing the above would be trivial, but also break window.open() (for the about 
blank case and likely the data: URI case too). To fix this looks like a headache. 
Since an about:blank RenderView is not associated with a MAIN_FRAME resource load in 
the browser, then no ViewMsg_SetContentSettingsForLoadingHost is ever sent & 
received.

Ideas:
Inheriting the settings from the window.opener context would take care of matters. 
This would also eliminate the need for 1), but I worry about having access to a 
reliable window.opener WebView & RenderView object in the case that rel="noreferrer" 
was used (forces window.open to create new process).

Investigating :)

Oops, did not mean to bail on this and assign to Darin _quite_ yet.
I believe you are reiterating the points I made on comment 9.  I think Darin's proposed 
fix that I described there is still relevant.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=43792 

------------------------------------------------------------------------
r43792 | cevans@chromium.org | 2010-04-06 17:53:02 -0700 (Tue, 06 Apr 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=43792&r2=43791

Fix plugin (and other) block settings for windows opened simply with
window.open(). Such cases should inherit settings from the parent.

BUG= 39740 
TEST=TODO
TBR=darin

Review URL: http://codereview.chromium.org/1524014
------------------------------------------------------------------------

Labels: SecSeverity-Low
Status: FixUnreleased
Labels: -SecSeverity-Low SecSeverity-Medium
Labels: -Restrict-View-SecurityTeam
Status: Fixed
Releasing: fixed in 5.0.375.55
Labels: Type-Security
Labels: SecImpacts-Stable
Batch update.
Project Member Comment 41 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 42 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Feature-Privacy -Mstone-5 -SecSeverity-Medium -Type-Security -SecImpacts-Stable Cr-Privacy M-5 Security-Severity-Medium Cr-Internals Security-Impact-Stable Type-Bug-Security
Project Member Comment 43 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 44 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 45 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Severity-Medium Security_Severity-Medium
Project Member Comment 46 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 47 by sheriffbot@chromium.org, Oct 1 2016
Labels: Restrict-View-SecurityNotify
Project Member Comment 48 by sheriffbot@chromium.org, Oct 2 2016
Labels: -Restrict-View-SecurityNotify
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment