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



Sign in to add a comment
link

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

Reported by aa...@xqz.ca, 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: 30.0.0.134
 
Screenshot 2018-07-14 at 13.44.43.png
389 KB View Download

Comment 1 by kerrnel@chromium.org, Jul 19 2018

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

Comment 2 by cthomp@chromium.org, 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 aa...@xqz.ca, Jul 20 2018

Variations:
6a89113b-ccb9a6a5
d01ab0d3-f23d1dea
59aeb88e-3f4a17df
ebeb14fc-3f4a17df
34a6bf44-3d47f4f4
64da5c1e-f23d1dea
b1681d28-803f8fc4
9041608a-f23d1dea
38eb801c-3f4a17df
7c1bc906-8122a015
47e5d3db-3d47f4f4
125b7f68-39db89b5
d442dfb7-41afa35c
1149accc-3f4a17df
4dc30737-b8a5ea08
a582a1b8-ad75ce17
3042ad4b-ca54bb47
98be3390-d93a0620
267255c3-f4950e99
116c6887-d7bc6f45
44827ee5-3f4a17df
edbcf7c5-90fc1f8
5485fc4d-ca7d8d80
9773d3bd-f23d1dea
93731dca-3d47f4f4
9e5c75f1-e10fa620
f79cb77b-3f4a17df
4ea303a6-ecbb250e
bcc34a89-3f4a17df
6e6e0c7e-f23d1dea
d92562a9-cfe3c2ea
4da5ae82-f23d1dea
2c1d398c-3f4a17df
6973a1cf-3f4a17df
4932440-d21eb72d
ff29b1bd-54dd8886
da460ac8-3f4a17df
4bc337ce-69465896
d1466cda-f23d1dea
9a2f4e5b-3fe32955
17507c76-3f4a17df
494d8760-52325d43
3ac60855-486e2a9c
f296190c-f2ffe33a
4442aae2-d7f6b13c
ed1d377-e1cc0f14
12e17bc5-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-6754d7b7
e7e71889-e1cc0f14
469cffe2-21549ebe
3a4029d-ca7d8d80
81c6897f-3f4a17df


Cheers.

Comment 4 by sheriffbot@chromium.org, Jul 20 2018

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

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

Comment 5 by cthomp@chromium.org, Jul 20 2018

Cc: r...@chromium.org mea...@chromium.org
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]:

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

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

[1] https://textslashplain.com/2017/01/14/the-line-of-death/

Comment 6 by cthomp@chromium.org, Jul 20 2018

Forgot to upload the screenshots of the UI in question.
extension-context-menu.png
25.8 KB View Download
extension-popover.png
45.2 KB View Download
chrome-menu.png
58.4 KB View Download
bookmark-bubble.png
28.9 KB View Download
page-info-bubble.png
59.3 KB View Download

Comment 7 by aa...@xqz.ca, 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 cthomp@chromium.org, 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 sheriffbot@chromium.org, Jul 21 2018

Project Member
Labels: M-68 Target-68

Comment 10 by sheriffbot@chromium.org, 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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 11 by bhthompson@google.com, Jul 23 2018

Cc: abodenha@chromium.org
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 cthomp@chromium.org, Jul 23 2018

Cc: groby@chromium.org
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 abodenha@chromium.org, Jul 23 2018

Cc: x...@chromium.org
xdai@ is this something you or someone on your team can look into?

Comment 14 by x...@chromium.org, Jul 23 2018

Owner: sammiequon@chromium.org
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 cthomp@chromium.org, 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 sammiequon@chromium.org, Jul 24 2018

Cc: sammiequon@chromium.org
Owner: afakhry@chromium.org
+afakhry

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

I bisected to https://chromium-review.googlesource.com/c/chromium/src/+/961722. Ahmed, could you take a look?

Comment 17 by afakhry@chromium.org, Jul 24 2018

Cc: pkasting@chromium.org ainslie@chromium.org
+pkasting@, +ainslie@ Is there a spec for the Y-coordinate of those popovers?

Comment 18 by ainslie@chromium.org, Jul 25 2018

Cc: bettes@chromium.org
+bettes@ will know

Comment 19 by pkasting@chromium.org, 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 sheriffbot@chromium.org, Jul 25 2018

Project Member
Labels: -Security_Impact-Beta Security_Impact-Stable

Comment 21 by cthomp@chromium.org, 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 cthomp@chromium.org, Jul 25 2018

Labels: -Pri-1 Pri-2

Comment 23 by pkasting@chromium.org, 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 aa...@xqz.ca, 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 afakhry@chromium.org, Aug 27

Cc: pbos@chromium.org
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 https://chromium-review.googlesource.com/c/chromium/src/+/1152525.

pkasting@ can you please confirm this is WAI before I close this issue?
material-touch-optimized.jpg
291 KB View Download
material-refresh.jpg
306 KB View Download
material-refresh-touch-optimized.jpg
319 KB View Download

Comment 26 by cthomp@chromium.org, 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 aa...@xqz.ca, 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 sheriffbot@chromium.org, Sep 5

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

Comment 29 by pbos@chromium.org, Sep 17

Cc: afakhry@chromium.org
Labels: -M-69 M-70
Owner: pbos@chromium.org
Status: Fixed (was: Assigned)
Re #25: https://chromium-review.googlesource.com/c/chromium/src/+/1152525 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 cthomp@chromium.org, 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 sheriffbot@chromium.org, Sep 18

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

Comment 32 by awhalley@chromium.org, Sep 24

Labels: reward-topanel

Comment 33 by awhalley@google.com, 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 awhalley@google.com, Oct 15

Labels: Release-0-M70

Comment 35 by awhalley@chromium.org, Oct 16

Labels: CVE-2018-17477 CVE_description-missing

Comment 36 by awhalley@chromium.org, Nov 12

Labels: -CVE_description-missing CVE_description-submitted

Comment 37 by sheriffbot@chromium.org, 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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment