1346123 - Trapping the user in fullscreen by using modal search dialog alerts (and blocking F11)

Status: UNCONFIRMED

(Firefox :: General, defect)

Description

[Abdulrahman Alqabandi]

Attachment: spoofer.html

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

By utilizing an annoying error dialog, we are able to trap a user inside an F11 fullscreen mode. We can potentially spoof any given URL with a lock icon as well as have the ability to display any html we like.

Follow instructions in attached PoC


Actual results:

Spoof + fullscreen trap


Expected results:

Mostly not allowing error dialog to trap user in fullscreen.

Comment 1

[Abdulrahman Alqabandi]

Attachment: spoofer.html

Here is a better PoC that prevents the user from escaping fullscreen by pressing f11 again, there is no escape!

Comment 2

[:Gijs (he/him)]

Xidorn, any ideas what we can do about this? We can make the F11 shortcut (and friends) reserved, I guess, and we can move the modal dialog in-content even in e10s... (which I advocated for in bug 1222107). Maybe we need to audit other places where we can throw up modal prompts?

FWIW, I can still exit all of these relatively easily, by simply moving my mouse to the top and hitting escape or enter when the dialog pops up. But I guess this would be annoying for a lot of users.

On the other hand, the spoof is obviously a lot less convincing if it's popping up this bizarre "can't install this search engine" alert. I'm also confused why it's allowed without any user interaction. Can sites just driveby-install search engines? I didn't think so... Mike?

Comment 3

[:Gijs (he/him)]

Also, maybe we should just force-turn-off fullscreen if an actual modal alert() dialog does manage to pop up (from the prompt manager).

Comment 4

[Mike Kaply [:mkaply]]

> I'm also confused why it's allowed without any user interaction. Can sites just driveby-install search engines? I didn't think so... Mike?

They can driveby try to install search engines, but there will always be a dialog to interact.

https://developer.mozilla.org/en-US/docs/Web/API/Window/sidebar

> Also, maybe we should just force-turn-off fullscreen if an actual modal alert() dialog does manage to pop up (from the prompt manager).

That seems like a good solution to me.

Comment 5

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #4)
> > I'm also confused why it's allowed without any user interaction. Can sites just driveby-install search engines? I didn't think so... Mike?
> 
> They can driveby try to install search engines, but there will always be a
> dialog to interact.
> 
> https://developer.mozilla.org/en-US/docs/Web/API/Window/sidebar

Can we avoid allowing them to do this without interaction with the site using the same criteria as the popup blocker?

Comment 6

[Mike Kaply [:mkaply]]

> Can we avoid allowing them to do this without interaction with the site using the same criteria as the popup blocker?

I don't think reusing that permission makes sense here. There are mainstream sites that use this API like AMO, http://mycroftproject.com/. Getting someone to set popup permission to install search engines from those sites seems counterintuitive.

I'm wondering if this is a candidate to switch over to doorhangers though...

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

(In reply to :Gijs from comment #5)
> Can we avoid allowing them to do this without interaction with the site
> using the same criteria as the popup blocker?

I think this is what we should do.

(In reply to Mike Kaply [:mkaply] from comment #6)
> I don't think reusing that permission makes sense here. There are mainstream
> sites that use this API like AMO, http://mycroftproject.com/. Getting
> someone to set popup permission to install search engines from those sites
> seems counterintuitive.

I think the idea here is that, only events like click / mouse{up,down} / key{press,down,up} are allowed to call the function. There is nothing about the popup permission.

This kind of modal dialogs can form a general DoS attack as well. Consider code like:
> <!DOCTYPE html>
> <script>
> setInterval(function() {
>   window.sidebar.addSearchEngine('Google:Login',1,1,1);
> }, 100);
> </script>
It would make you impossible to interact with Firefox normally anymore.

And consider the following code:
> <!DOCTYPE html>
> <script>
> while (true) {
>   window.sidebar.addSearchEngine('Google:Login',1,1,1);
> }
> </script>
This freezes the parent process forever.

So I believe it is a more general issue than a fullscreen issue.

We should avoid this kind of modal dialog, and probably create a general mechanism to regulate their appearence.

For this specific case, I think making the install behavior only happen in the event handlers which are allowed to open popup is the most sensible solution.

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

We should probably examine all modal dialog usages in Firefox and consider whether they should be modal dialog, whether they can be triggered via content.

It reminds me of bug 1236381 which can be used to form similiar DoS attack as well.

Comment 9

[Abdulrahman Alqabandi]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #8)
> We should probably examine all modal dialog usages in Firefox and consider
> whether they should be modal dialog, whether they can be triggered via
> content.
> 
> It reminds me of bug 1236381 which can be used to form similiar DoS attack
> as well.

Bug 1229873 is another dialog that could be abused.

Comment 10

[Abdulrahman Alqabandi]

Attachment: dialogs.html

Here are a few other dialogues:

Comment 11

[Daniel Veditz [:dveditz]]

Un-hiding at the reporter's request.

Comment 12

[Jonathan Kingston [:jkt] he/him]

Sounds like Chrome is considering fixing traps like this: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/8Z36QLPkCd0/xrGkjvLcAAAJ

This could be fixed by escaping fullscreen until the user has finished interacting with a doorhanger.

Comment 13

[Andrea Marchesini [:baku]]

This test uses a non-existing window.sidebar.addSearchEngine(). This method is now been replaced by: window.external.AddSearchProvider().

I just submitted a patch to get rid of window.external.AddSearchProvider() - Bug 1503551. We are the only browser to implement this feature. The fix consists in the introduction of a pref: dom.sidebar.enabled, false by default in nightly. Let's keep it false in nightly only for 1 or 2 cycles just to be 100% sure we don't introduce regressions.