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

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Feb 2011
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Open popup in new tab using java applet

Reported by chamal.d...@gmail.com, Jan 23 2011

Issue description

VULNERABILITY DETAILS
It is possible to open a popup in new tab using java applet.
But it is not possible to open a popup on new window as with window.open().

VERSION
Chrome Version: [8.0.552.224] + [stable]
                [10.0.647.0 (72276)] + [dev]
Operating System: [Ubuntu 10.04, 32 bit]

REPRODUCTION CASE
1. Copy attached MMotion.html and Pop.class to same folder.
2. Open MMotion.html in chrome.
   This page contains Pop.class applet.
3. Move the mouse over applet.
   google.com will be loaded in new tab.


 
Pop.class
1.2 KB Download
MMotion.html
91 bytes View Download
Pop.java
753 bytes View Download
@abarth: do you happen to know if it was always our intent to block pop-ups initiated by plug-ins?

Comment 3 by jnd@chromium.org, Jan 27 2011

So the question is why the java applet can not open a popup on new window, right?
Yes, the test can open a new tab instead of a new window, it's because it didn't provide enough information to Chrome, please see logic in  ChromeClientImpl::show().
I don't know how to let the java applet provide those window features like what window.open does.

Comment 4 by jsc...@chromium.org, Jan 27 2011

So, does this seem like a bug in the Java plugin, as opposed to Chrome?
I still suspect a Chrome bug. Chrome should be blocking _both_ an attempt to open a new window and an attempt to open a new tab.
Chrome knows when it is doing either of those things.

The only missing piece might be the awareness as to whether or not a user gesture is in progress?
@scarybeasts 
yes. it seems to be user gesture is missing.

third_party/WebKit/Source/WebCore/bindings/v8/ScriptController.cpp's processingUserGesture method returns false in this code section.

if (!activeFrame)  //activeFrame is null
        return UserGestureIndicator::getUserGestureState() != DefinitelyNotProcessingUserGesture;
//UserGestureIndicator::getUserGestureState() equals to PossiblyProcessingUserGesture which is the default value in UserGestureIndicator.
//I could not find any place where PossiblyProcessingUserGesture is set to UserGestureIndicator other than it's default value.  





Status: Started
I'll have a look on Monday
@chamal.desilva: well, this is interesting. There's definitely a Chrome bug here.

There's also a bug in the official Java plug-in for Linux -- it always forces pop-ups to be allowed. You can see that your repro also works in Firefox, if the official Java plug-in is used.

If we used IcedTea (based on OpenJDK), things are different. It does not always force pop-ups, and Firefox blocks them whereas Chrome does not. This I can fix.
Hmm, in the Linux Firefox + IcedTea case, Firefox also has a bug: it erroneously blocks pop-ups resulting from a click in the plug-in.
Ok, so it's not a Firefox bug; it's just opposite bugs in official JRE vs. IcedTea JRE :)

official: always forces pop-ups on, regardless of whether a user click was involved.
IcedTea: always forces pop-ups off, regardless of whether a user click was involved.

Chrome is not obeying the IcedTea case.
Project Member

Comment 11 by bugdroid1@chromium.org, Feb 2 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=73417

------------------------------------------------------------------------
r73417 | cevans@chromium.org | Tue Feb 01 19:14:26 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/npapi/webplugin_impl.h?r1=73417&r2=73416&pathrev=73417
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/npapi/webplugin_impl.cc?r1=73417&r2=73416&pathrev=73417

Propagate the user gesture state. It is necessary to do correct pop-up blocking
if a plug-in tries to open an URL in a new frame.
No behaviour changes yet -- those require a separate change to the WebKit
chromium directory, that uses the propagated state.

BUG= 70538 
TEST=NONE

Review URL: http://codereview.chromium.org/6392042
------------------------------------------------------------------------
Labels: -Pri-0 Pri-2 SecSeverity-Low Mstone-11
Status: Fixed
Ok, I'm still fixing Linux test issues left right and center but the security bug is about as "Fixed" as it can be in Chrome.

Unfortunately, the official Java plug-in is fundamentally broken. It forces pop-ups on irregardless of whether the user clicked on anything or not. You can confirm this by taking Chrome out of the equation: try Windows + Firefox or Windows + IE, with Java installed. The pop-ups are not blocked, so nice discovery :)

The IcedTea JRE plug-in (more common on Linux) _never_ sets popups enabled, so pop-up blockers will block even if the window resulted from a user click. Chrome used to fail to block with IcedTea; that bug is now fixed. At least IceaTea users get relief. That said, I don't recommend anyone surfs with any form of Java plug-in widely enabled.
WebKit part of this change was:
https://bugs.webkit.org/show_bug.cgi?id=53571
Committed r77367: <http://trac.webkit.org/changeset/77367>

And I'm piling test fixes and enhancements into http://code.google.com/p/chromium/issues/detail?id=30700
It's great. It works fine now :)
Labels: Type-Security
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify CVE-2011-1304
Status: FixUnreleased
Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Project Member

Comment 20 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 21 by bugdroid1@chromium.org, Mar 10 2013

Labels: -SecSeverity-Low -Mstone-11 -Type-Security -SecImpacts-Stable Security-Severity-Low Security-Impact-Stable M-11 Type-Bug-Security
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-Undefined
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 26 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 27 by sheriffbot@chromium.org, Oct 2 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
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment