1620920 - UI Spoofing: chrome.windows.create of WebExtensions can create a fullscreen window without a warning

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[filedescriptor]

Attachment: spoof_fullscreen_ext.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Description:
The chrome.windows.create API of WebExtensions has a state parameter which can be specified to "fullscreen". A window created with this will be opened in full screen mode without the indication of it being a web page in fullscreen. The API does not require any permission of WebExtensions and can be used to spoof the browser UI (and OS UI if you will).

Steps to Reproduce:

1. Load the attached extension zip as a temporary add-on
2. A fake Chrome UI will appear covering the full screen

Comment 1

[filedescriptor]

Attachment: normal_fullscreen.png

A normal webpage in fullscreen will have an indicator of the website's origin

Comment 2

[Johann Hofmann [:johannh]]

Yeah there should be an indicator like it's shown on websites when the page goes into full-screen. Also, pressing ESC to exit doesn't seem to be supported to exit that window, which is probably intentional but it would be great if ESC could spawn the fullscreen indicator or something at least.

Anyway, I would argue that this is sec-low since it requires installation of a WebExtension which is already quite a big escalation of privilege.

Ultimately this isn't much worse than bug 1400252, IMO, which is public. So it's probably fine to open this up, but I'll wait for a second opinion.

Comment 3

[filedescriptor]

From a somewhat related discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=1296365#c4

It seems that popups have their own "security indicator" that always shows the true URL in the window title, so I would say that's somewhat mitigated (although I think not enough).

Comment 4

[Shane Caraveo (:mixedpuppy)]

We should consider preventing extensions doing content-full-screen mode like this, and instead make it chrome-full-screen mode. This way, the tabstrip and urlbar will be visible.

The other consideration would be to make sure that full-screen controls work appropriately, which would be more Chrome compatible.

We don't feel this is a security issue at this time.

ni?Fallen to look into this further.

Comment 5

[Shane Caraveo (:mixedpuppy)]

We discussed this at length.

Firefox doesn't show any panel for this full screen mode, primarily because it requires user interaction to get into it.
We cannot backtrack and require user input for this particular option since that would break extensions.
So we would have to add an extension-specific panel, similar to the in-content-fullscreen mode.

After trying the example extension, I think we need to do something here, as it does provide a fullscreen appearance. It is not in-content fullscreen, but given the combination of options, they are acheiving somethign we should probably disallow. For this particular combination (panel + fullscreen), it might be ok to require user interaction. We could also simply disallow the combination.

chrome.windows.create({ url, type: 'panel', state: 'fullscreen' })

Comment 6

[Johann Hofmann [:johannh]]

Thanks for the update! That comment seems reasonable :)

Comment 7

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 8

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 9

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 10

[Firefox Bug Husbandry Bot]

The severity of these bugs was changed, mistakenly, from normal to S3.

Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.