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

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
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.
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

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
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.
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
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
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.
Project Member

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

Labels: -Pri-2 Pri-1
Project Member

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

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
Project Member

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

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
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?
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? 
did you ask me that already at  http://crbug.com/550017#c24  ?
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).
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?
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? 
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.
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.
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 .
Project Member

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

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)
Project Member

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

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
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.
*********************************
Congratulations ma7h1as.l@! The VRP Panel has decided to award $1,000 for this report. Cheers!
Labels: -reward-unpaid reward-inprocess
Labels: -M-64 M-66
Project Member

Comment 46 by sheriffbot@chromium.org, Mar 16

Labels: Merge-Request-66
Project Member

Comment 47 by sheriffbot@chromium.org, Mar 16

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
Labels: -Merge-Review-66
No need for merge. 
Labels: Release-0-M66
Labels: CVE-2018-6096
Labels: CVE_description-missing
Project Member

Comment 52 by sheriffbot@chromium.org, May 25

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

Sign in to add a comment