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
Closed: Sep 17
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 863703: Extension popovers do not overlap the Chrome, so they can be spoofed in the viewport.

Reported by, Jul 14 2018

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 10718.50.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.59 Safari/537.36
Platform: 10718.50.0 (Official Build) beta-channel cyan

Steps to reproduce the problem:
1. Install an extension which has a popover
2. Open the extension's popover

What is the expected behavior?
The popover should continue visually into/over the browser Chrome, so that it is obvious that they could not come from the viewport.

What went wrong?
The popover was rendered as a box entirely contained within the viewport, so could be spoofed by a malicious page (except for the button down state).

Did this work before? Yes 67 stable

Chrome version: 68.0.3440.59  Channel: beta
OS Version: 10718.50.0
Flash Version:
Screenshot 2018-07-14 at 13.44.43.png
389 KB View Download

Comment 1 by, Jul 19 2018

Components: Platform>Extensions
Labels: OS-Linux OS-Mac OS-Windows

Comment 2 by, Jul 19 2018

Components: UI>Browser
Labels: Team-Security-UX Needs-Feedback
From your screenshot, it does appear that it is missing the pixel overlap for the line-of-death here. I think some of the new UI changes have gotten rid of the old chevron-style design for these popovers, which may exacerbate this.

Could you go to chrome://version and copy-paste the list of variations here? It looks like you might be in an inconsistent browser UI state where some of the new UI features are not all enabled.

[Specifically adding Team-Security-UX label to make sure Enamel can track this.]

Comment 3 by, Jul 20 2018



Comment 4 by, Jul 20 2018

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot

Comment 5 by, Jul 20 2018

Labels: -OS-Linux -OS-Windows -Pri-2 -OS-Mac Security_Severity-Medium Security_Impact-Beta FoundIn-68 FoundIn-69 Pri-1
Status: Available (was: Unconfirmed)
Thanks! I can replicate this on ChromeOS 68 Beta (without fiddling with any flags). The behavior is also the same on 69.0.3494.0 dev. Nothing in your list of variations looks like it would affect this.

On Linux Chrome 68 Beta (trying to match the version and variations you're in) I can't replicate, but the top Chrome UI is different in M68 (it looks like ChromeOS 68 Beta has some of the new UI design enabled by default). I also can't replicate it in Linux or Mac Chrome 69. Because of that, I'm marking this back as ChromeOS only, but will keep tracking it as a Security-UX bug. Also, tentatively calling this Severity-Medium.

Specifically, I see the following with the line-of-death [1]:

- The Page Info bubble correctly overlaps the line-of-death
- The bookmark bubble correctly overlaps the line-of-death

- Extension popovers do not overlap the line-of-death and in fact appear to have a ~1px gap between the bottom of the top chrome and the content area
- The right-click context menu for an extension has no gap but also does not overlap the line-of-death
- The main Chrome menu has no gap but also does not overlap the line-of-death

I'm not familiar with the top chrome UI differences between Linux Chrome and ChromeOS Chrome, so adding rkc@: Do you know what might be causing this or who would be a good owner?

Also adding meacer@ as another Security-UX team member who may have ideas.


Comment 6 by, Jul 20 2018

Forgot to upload the screenshots of the UI in question.
25.8 KB View Download
45.2 KB View Download
58.4 KB View Download
28.9 KB View Download
59.3 KB View Download

Comment 7 by, Jul 20 2018

Notably, even on Chromium 67.0.3396.99 on Linux, the degree to which extension popovers and bookmark/page info bubbles overlap the LoD is different. It seems to me that these Y offsets should be calculated relative to the LoD or the bottom of the chrome, from the same set of constants.

Comment 8 by, Jul 20 2018

Yep, I don't think the overlap has ever been very consistent, although I think this is more of an issue now that the chevrons are gone :-/

Comment 9 by, Jul 21 2018

Project Member
Labels: M-68 Target-68

Comment 10 by, Jul 21 2018

Project Member
Labels: ReleaseBlock-Stable
This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit - Your friendly Sheriffbot

Comment 11 by, Jul 23 2018

This bug needs to be fixed and merged back within the next week or it will start blocking our R68 stable release.

Whom is the right owner for this?

Comment 12 by, Jul 23 2018

groby@ Do you know who could be a good owner for this? This is Views UI but it appears to only be manifesting on ChromeOS.

Comment 13 by, Jul 23 2018

xdai@ is this something you or someone on your team can look into?

Comment 14 by, Jul 23 2018

It seems to me that it might caused by the disappeared chevrons. Anyone know if the chevrons were removed in 68?

sammiequon@, can you take a look? It's a regression in 68 and we probably should either find the CL that caused it or find a fix for it.

Comment 15 by, Jul 23 2018

Status: Assigned (was: Available)
Yes, the designs for GM2 Refresh UI do not include the chevrons (per go/crux-gm2). However, these bubbles are clearly misaligned vertically compared to prior UI and to non-Chrome OS platforms. The chevrons are a UI decision (which we may want to debate later), while the alignment here is a bug.

Comment 16 by, Jul 24 2018


This was in here for a while but behind the flags SecondaryUiMd and --top-chrome-md=material-touch-optimized.

I bisected to Ahmed, could you take a look?

Comment 17 by, Jul 24 2018

+pkasting@, +ainslie@ Is there a spec for the Y-coordinate of those popovers?

Comment 18 by, Jul 25 2018

+bettes@ will know

Comment 19 by, Jul 25 2018

Things inside the omnibox are supposed to align with the base of the omnibox.  For things outside the omnibox, it's less clear.  On non-touchable, they happen to line up with the base of the omnibox.  I don't think it's necessarily a bug that on touchable they line up with the base of the toolbar as in comment 6.

The sentiment behind wanting to make things unspoofable is a good and noble one, but I would be surprised to find any user testing showing that the particular methods we've been using have been effective.  I am skeptical that the actual (as opposed to theoretical) user harm of shipping this rises to the RBS level.

Comment 20 by, Jul 25 2018

Project Member
Labels: -Security_Impact-Beta Security_Impact-Stable

Comment 21 by, Jul 25 2018

Labels: -Security_Severity-Medium -ReleaseBlock-Stable Security_Severity-Low
Since this is only occurring for less important UI (extension popovers and the chrome menu, rather than for e.g. Page Info where we'd have stronger consequences for spoofing), I'd be fine with lowering this to Severity-Low and removing RBS.

I would still argue that this is a bug -- Chrome's UI has generally tried to maintain this guarantee in the past (such as with the use of chevrons) and all other platforms (and even other UI on this platform) ensure an overlap.

Comment 22 by, Jul 25 2018

Labels: -Pri-1 Pri-2

Comment 23 by, Jul 25 2018

It's true, we tried pretty intentionally to give some indicator, and moved away from doing that.  I'm just skeptical that we did much good with the indicators (and I think the designers are too).  My totally-unproven hypothesis is that there's a large group of people who still believed spoofed versions, and a smaller group of people who wouldn't believe the spoofed versions now even though it's theoretically harder to tell them apart.

Comment 24 by, Jul 26 2018

It may be the case that a generic user could likely fall for a spoof even with the previous designs, if they are not a regular user of extensions with popovers, but for the subset of users who pay attention to this as an operational necessity (I have seen training slides at workplaces specifically talking about spoofed extension popovers), the reward/risk of a spoof of this sort is high.

Just my two cents.

I could probably fix this, assuming it is a simple matter of changing the y offset calculation. The question of whether or not the popover ovelaps the LoD seems to be a minor/incidental outcome of the new design, so changing it to overlap (like the other popovers/bubbles) should be equally minor a change.

Comment 25 by, Aug 27

I can no longer repro this issue. The top line of the popup is always above the toolbar bottom separator. Attached are some examples in different MD modes.

I believe this was fixed by pbos@ in

pkasting@ can you please confirm this is WAI before I close this issue?
291 KB View Download
306 KB View Download
319 KB View Download

Comment 26 by, Aug 27

From your screenshots, I agree that that this appears to be fixed now (also, I hadn't previously seen  Issue 800372 ). I don't have a touchable device to test on myself right now however.

Comment 27 by, Aug 28

Can confirm that the current Beta channel image on the same Chromebook (touch-enabled Cyan) no longer exhibits this issue (though the size of the UI seems to have shrunk in general, so it's possible this is due to something else, maybe the device is no longer being treated as "touch-optimized").
Screenshot 2018-08-28 at 15.04.32.png
132 KB View Download

Comment 28 by, Sep 5

Project Member
Labels: -M-68 M-69 Target-69

Comment 29 by, Sep 17

Labels: -M-69 M-70
Status: Fixed (was: Assigned)
Re #25: intentionally fixes it (I just heard about it through the grapevine and didn't know that there was a canonical bug for it). Since this is Severity-Low can we wait for this to just trickle in instead of backporting it?

Re #27: I believe M69 changes ChromeOS behavior so that only certain tablet devices are "touch-enabled" (not just if they have a touch screen). As a result Cyan probably no longer thinks it's a touch-only device and reverts back to using non-touch sizes. This restricts the number of devices that are impacted by this.

Let me know if anyone feels strongly that this warrants a merge, otherwise I think this can be left alone. Thanks!

Comment 30 by, Sep 17

Great, thanks! Since that fix made M70 I think we'd be fine not merging back to M69 Stable for this (and I don't know if there are any other respins planned).

Comment 31 by, Sep 18

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

Comment 32 by, Sep 24

Labels: reward-topanel

Comment 33 by, Sep 28

Labels: -reward-topanel reward-0
Thanks for the report aaron@! I'm afraid that our VRP panel declined to reward for this (as we often tend not to for low severity bugs).

Comment 34 by, Oct 15

Labels: Release-0-M70

Comment 35 by, Oct 16

Labels: CVE-2018-17477 CVE_description-missing

Comment 36 by, Nov 12

Labels: -CVE_description-missing CVE_description-submitted

Comment 37 by, Dec 25

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 - Your friendly Sheriffbot

Sign in to add a comment