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 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Security

Blocking:
issue 800056



Sign in to add a comment
link

Issue 776418: Security: Fullscreen notification can be overlapped

Reported by ma7h1a...@gmail.com, Oct 19 2017

Issue description

AFFECTED PRODUCTS
--------------------
chrome 62 stable


DESCRIPTION
--------------------
attacker could call an alert function in the popup without exit fullscreen mode
and overlay the security notification
bypass the patch of CVE-2017-15386 ( issue 752003 )
Online demo http://xsser.math1as.com/bypass.html
 

Comment 1 by ma7h1a...@gmail.com, Oct 19 2017

as a result: the old patch just exit fullscreen when window.open is called, so it is not a good idea just block window.open

Comment 2 by elawrence@chromium.org, Oct 19 2017

Cc: a...@chromium.org
Components: UI>Browser>FullScreen
Summary: Security: Fullscreen notification can be overlapped (was: Security: UI Spoofing in blink)
This POC results in a blocked popup notification and then a few misplaced windows. Can you please explain in prose what you're trying to accomplish and include screenshots demonstrating the effect?

I /think/ you're simply noting that a window.open()-spawned window can be placed above the notification that a window has gone full-screen? Is that right?

Comment 3 by ma7h1a...@gmail.com, Oct 19 2017

yes,a popup window would overlay the notification
the result behaves the same with comment #9 in  issue 752003 
(attacker draws a fake addressbar on the top of this page, but user would not know because of the notification is overlapped)

Comment 4 by kenrb@chromium.org, Oct 19 2017

elawrence, avi: Random question... both window.open() and the fullscreen API require user gestures. Apparently not separate ones, though. Does one of them not consume the gesture?

Comment 5 by a...@chromium.org, Oct 19 2017

I don't believe fullscreen requires a gesture, but I'm not sure. You'd have to ask a gesture person.

Meanwhile, window.open() is supposed to kick the caller out of fullscreen. I fixed that a few months ago. Is that broken? (Looking at the repro now.)

Comment 6 by a...@chromium.org, Oct 19 2017

Is what's going on that while new popups kick the caller out of fullscreen, you can reposition old ones, and activate them with alert dialogs?

Comment 7 by ma7h1a...@gmail.com, Oct 19 2017

yes,now window.open() would kick the caller fullscreen mode
but this poc shows a way to bypass your rule
3 steps:
1. window(A) open window(B) (about:blank)
2. window(A) open window(C) (page with a fake addressbar)
3. window(C) request fullscreen mode , then i call alert function on window(B)
so that window(B) overlay the notification on window(C)

Comment 8 by ma7h1a...@gmail.com, Oct 19 2017

Re #6
the window.open is called before request fullscreen API
so that window(C) would not be kicked out of fullscreen

Comment 9 by a...@chromium.org, Oct 19 2017

This is mitigated by running against the popup blocker, then. I needed to disable it to see what you're doing.

Comment 10 by ma7h1a...@gmail.com, Oct 20 2017

Re #2
Re #9

now I write a POC which would show this attack (similar with  issue 752003 )
and do not need to disable anything

Online Demo http://xsser.math1as.com/fullscreen.html

Comment 11 by ma7h1a...@gmail.com, Oct 20 2017

and here comes the attack.gif
shows a same attack result with the old bug
so this is how i bypass the patch
attack.gif
170 KB View Download

Comment 12 by tsepez@chromium.org, Oct 20 2017

Labels: Security_Severity-Medium Security_Impact-Stable M-63 Pri-2
Owner: a...@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 13 by a...@chromium.org, Oct 20 2017

First, this isn't a critical issue because this requires the popup blocker to be disabled.

Second, I'm not sure what to do here. Can we make the fullscreen bubble always be on top of browser windows?

I'm removing activation from everything I can, which will fix this, though that's currently an ongoing project.

Comment 14 by ma7h1a...@gmail.com, Oct 20 2017

Re #13
follow my new POC , if user give a gesture(click the link) instead of using window.open , it would not need the popup blocker to be disabled

Comment 15 by ma7h1a...@gmail.com, Oct 20 2017

Re #13
your second problem is easy to be answered
in the old bug,the patch kick the opener out of fullscreen
in this bug,if any function like alert,prompt is called , you could kick the window's opener out of fullscreen mode

Comment 16 by ma7h1a...@gmail.com, Oct 20 2017

old patch: Window A open Window B, B kick out its opener
new patch: Window A open Window B,Window B call alert,prompt,focus function, B kick out its opener

Comment 17 by avi@google.com, Oct 20 2017

The problem is that the window that is calling alert/prompt isn't the window that's in fullscreen.

Right now the removal of activation is my solution here.

Comment 18 by sheriffbot@chromium.org, Oct 22 2017

Project Member
Labels: -Pri-2 Pri-1

Comment 19 by sheriffbot@chromium.org, Nov 4 2017

Project Member
avi: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 20 by sheriffbot@chromium.org, Nov 18 2017

Project Member
avi: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 21 by palmer@chromium.org, Dec 4 2017

Cc: benwells@chromium.org raymes@chromium.org est...@chromium.org
Labels: -M-63 M-64 Team-Security-UX OS-Chrome OS-Linux OS-Mac OS-Windows
+Security UX peeps

Any chance this can be fixed in M-64? M-63 has passed.

Comment 22 by a...@chromium.org, Dec 4 2017

Oh! I misunderstood what was going on, and thought that I needed to remove activation from dialogs.

Here's what happens:
1. The page has a link for a click. The user clicks, which shows a popup.
2. The page then refreshes to content that socially engineers another click from the user. The page uses that click to go fullscreen to a fake site. Meanwhile, the page calls focus() on the popup, which brings it to the front.

I thought the page was using dialogs to activate, rather than using window.focus(). If we look at the DOMWindow::focus() implementation, window.focus() is restricted to the case where the parent window is forcing a popup to be focused.

I'm not sure what to do here. We can drop our support for window.focus() entirely, but that kills the case where a page, say, uses a popup to implement a calendar control (the user focuses the main page again, and then the main page tries to hold the popup window above itself).

Is that a direction we want to pursue?

Comment 23 by raymes@chromium.org, Dec 5 2017

Cc: tapted@chromium.org mgiuca@chromium.org
tapted: is it possible to make this notification show up on top of all the windows? 

In general, if other windows show up above the fullscreen window, should we just exit fullscreen?

Comment 24 by tapted@chromium.org, Dec 5 2017

did you ask me that already at  http://crbug.com/550017#c24  ?

Comment 25 by raymes@chromium.org, Dec 5 2017

Sorry if I did! I just chatted again with mgiuca and it's not easy to control the stack order. What we want to do is exit fullscreen whenever a popup is triggered during fullscreen (i.e. there should never be anything on top of fullscreen).

Comment 26 by tapted@chromium.org, Dec 5 2017

hehe - sorry for the cheeky response :). I've caught up on the issue here. It's a lot of the same problems in  Issue 550017  .

I think on Mac we may be able to do something custom by setting a window level or using NSWindowStyleMaskHUDWindow . Apple's documentation for these really sucks btw :/. Using these may introduce other problems.

For Windows, there didn't seem to be a good alternative. There's `AlwaysOnTop` but that may also need us to break the parent/child relationship, which may break other things.

But these feel like workarounds anyway. Popups shouldn't work in fullscreen.

For example, if I go to http://xsser.math1as.com/fullscreen.html and press Ctrl+Cmd+f to get "AppKit" fullscreen on Mac, the popup shows in a tab. If you're in HTML5 fullscreen rather than AppKit fullscreen, booting a user out of fullscreen seems like the right fix.

Comment 27 by a...@chromium.org, Dec 5 2017

Please read comment 22.

We *already* drop fullscreen when a popup is displayed. In this case, the popup is *already there* when we go fullscreen. The main page calls window.activate() on the popup to bring it to the front.

What are you proposing? That _any_ activation of _any_ popup window breaks fullscreen of _all_ fullscreened elements?

Comment 28 by raymes@chromium.org, Dec 5 2017

Sorry I did read #22 but I didn't see the connection. I think that focussing another window over the fullscreen window should have the same effect of exiting fullscreen?

Comment 29 by tapted@chromium.org, Dec 5 2017

hm - we need to consider a dual-monitor setup. A user can have a fullscreen YouTube on one monitor, and regular browser windows on the other monitor. If a website makes a popup, it shouldn't boot YouTube out of fullscreen. If a website makes a popup, moves it to the other monitor, and activates it, it probably also shouldn't boot youtube out of fullscreen. But perhaps we can prevent window activation of the popup in this case, or prevent/moveout any popups that would overlap fullscreen windows.

Comment 30 by a...@chromium.org, Jan 5 2018

How about if a page calls window.activate(), it gets kicked out of fullscreen?

Activation is inherently a multiwindow action while fullscreen is immersive. They're contradictory.

Comment 31 by a...@chromium.org, Jan 5 2018

Reporter: http://xsser.math1as.com/fullscreen.html is not responding. Can you check it? I want to test a fix I'm working on.

Comment 32 by ma7h1a...@gmail.com, Jan 8 2018

I am sorry, i will fix it as soon as possible

Comment 33 by avi@google.com, Jan 8 2018

Blocking: 800056
Proposing a fix in  bug 800056 .

Comment 34 by avi@google.com, Jan 8 2018

ma7: No problem; thank you for maintaining your site and sorry for the delay.

Comment 35 by ma7h1a...@gmail.com, Jan 9 2018

re #34
already fixed, it works

Comment 36 by a...@chromium.org, Jan 9 2018

I just tested https://crrev.com/c/852378 against your POC and it works. I have it under consideration for an Intent on blink-dev.

Comment 37 by a...@chromium.org, Jan 24 2018

This appears to affect Firefox as well; filed https://bugzilla.mozilla.org/show_bug.cgi?id=1432856 .

Comment 38 by bugdroid1@chromium.org, Feb 1 2018

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36f801fdbec07d116a6f4f07bb363f10897d6a51

commit 36f801fdbec07d116a6f4f07bb363f10897d6a51
Author: Avi Drissman <avi@chromium.org>
Date: Thu Feb 01 20:06:04 2018

If a page calls |window.focus()|, kick it out of fullscreen.

BUG= 776418 ,  800056 

Change-Id: I1880fe600e4814c073f247c43b1c1ac80c8fc017
Reviewed-on: https://chromium-review.googlesource.com/852378
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Philip J├Ągenstedt <foolip@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533790}
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/browser/frame_host/render_frame_host_delegate.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/browser/web_contents/web_contents_impl_browsertest.cc
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/common/frame_messages.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/renderer/render_frame_impl.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/renderer/render_view_impl.cc
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/renderer/render_view_impl.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/shell/test_runner/web_view_test_client.cc
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/shell/test_runner/web_view_test_client.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/content/shell/test_runner/web_view_test_proxy.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/exported/WebViewTest.cpp
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/frame/DOMWindow.cpp
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/loader/EmptyClients.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/page/ChromeClient.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/page/ChromeClientImpl.cpp
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/page/ChromeClientImpl.h
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/Source/core/page/CreateWindow.cpp
[modify] https://crrev.com/36f801fdbec07d116a6f4f07bb363f10897d6a51/third_party/WebKit/public/web/WebViewClient.h

Comment 39 by a...@chromium.org, Feb 15 2018

Status: Fixed (was: Assigned)

Comment 40 by sheriffbot@chromium.org, Feb 16 2018

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 41 by awhalley@google.com, Feb 19 2018

Labels: reward-topanel

Comment 42 by awhalley@chromium.org, Feb 26 2018

Labels: -reward-topanel reward-unpaid reward-1000
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Comment 43 by awhalley@google.com, Feb 26 2018

Congratulations ma7h1as.l@! The VRP Panel has decided to award $1,000 for this report. Cheers!

Comment 44 by awhalley@chromium.org, Feb 27 2018

Labels: -reward-unpaid reward-inprocess

Comment 45 by awhalley@chromium.org, Mar 6 2018

Labels: -M-64 M-66

Comment 46 by sheriffbot@chromium.org, Mar 16 2018

Project Member
Labels: Merge-Request-66

Comment 47 by sheriffbot@chromium.org, Mar 16 2018

Project Member
Labels: -Merge-Request-66 Merge-Review-66 Hotlist-Merge-Review
This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 48 by abdulsyed@google.com, Mar 19 2018

Labels: -Merge-Review-66
No need for merge.

Comment 49 by awhalley@google.com, Apr 17 2018

Labels: Release-0-M66

Comment 50 by awhalley@chromium.org, Apr 25 2018

Labels: CVE-2018-6096

Comment 51 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-missing

Comment 52 by sheriffbot@chromium.org, May 25 2018

Project Member
Labels: -Restrict-View-SecurityNotify allpublic
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

Comment 53 by awhalley@chromium.org, Jan 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment