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

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
2 years ago
13 days ago

People

(Reporter: qab, Unassigned)

Tracking

(Blocks: 1 bug, {csectype-dos, csectype-spoof, sec-low})

55 Branch
Unspecified
Windows
csectype-dos, csectype-spoof, sec-low
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8845753 [details]
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.
(Reporter)

Comment 1

2 years ago
Created attachment 8845765 [details]
spoofer.html

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

Comment 2

2 years ago
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?
Component: Untriaged → General
Flags: needinfo?(xidorn+moz)
Flags: needinfo?(mozilla)
Summary: Omnibox spoof by trapping user in fullscreen → Trapping the user in fullscreen by using modal search dialog alerts (and blocking F11)

Comment 3

2 years ago
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

2 years ago
> 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.
Flags: needinfo?(mozilla)

Comment 5

2 years ago
(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

2 years ago
> 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...
(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.
Flags: needinfo?(xidorn+moz)
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.
(Reporter)

Comment 9

2 years ago
(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.
(Reporter)

Comment 10

2 years ago
Created attachment 8846237 [details]
dialogs.html

Here are a few other dialogues:
Keywords: sec-low
Un-hiding at the reporter's request.
Group: firefox-core-security
Keywords: csectype-dos, csectype-spoof
OS: Unspecified → Windows
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.
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.
Depends on: 1503551
You need to log in before you can comment on or make changes to this bug.