1621424 - Bypass PopUp Blocking via simulate click

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect, P1)

Description

[Guilherme Keerok]

Attachment: simulate.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36

Steps to reproduce:

1. Go to https://jsfiddle.net/keer0k/bvyd2xfo/3/
2. Run it
3. Click in "click me"
4. A new window will be open and, after a few seconds, more 2 windows will be opened too

Actual results:

3 windows are opening

Expected results:

only one window needs to open

Comment 1

[Johann Hofmann [:johannh]]

Ok, yeah, this is pretty bad. Modifying your test case I can spawn an unlimited amount of popups with arbitrary delay and rhythm, DOSing the browser and heavily affecting the OS as well.

Baku, this should be fixed as of bug 675574, but apparently this presents a loophole. Do you have time to look into the bug or should we ask someone else?

Comment 2

[Johann Hofmann [:johannh]]

Attachment: Updated + simplified testcase for unlimited popups

Comment 3

[:Gijs (he/him)]

Perhaps related to bug 1185052?

Comment 4

[Daniel Veditz [:dveditz]]

Huh, thought we had fixed this one. Interesting bypass.

Comment 5

[Andrea Marchesini [:baku]]

This is not related to the simulated click. The problem is this:

1. the user clicks on the button. This button runs X times a function which (directly or indirectly) creates a timer.
2. Now we have X timers, each one of them created by user-interaction.
3. When those timers run, they are all allowed to open a window.

A simple version of that test is:

for (let i = 0; i < 3; i++) {
  document.getElementById("button").addEventListener('click', () => {
    setTimeout(() => window.open(location.href,"_blank","toolbar=yes,scrollbars=yes,resizable=yes,top=500,left=500,width=400,height=400"));
  });
}

Comment 6

[:Gijs (he/him)]

(In reply to Andrea Marchesini [:baku] from comment #5)

This is not related to the simulated click. The problem is this:

1. the user clicks on the button. This button runs X times a function which (directly or indirectly) creates a timer.
2. Now we have X timers, each one of them created by user-interaction.
3. When those timers run, they are all allowed to open a window.

So in bug 675574 when you patched things to only allow 1 popup per event - is the event tracked on something other than the timer? Can we somehow refer back to this "original" event where we will have switched the blocked state to blocked?

Comment 7

[Andrea Marchesini [:baku]]

Attachment: Bug 1621424 - Revoke popup token in timeouts at the first window.open, r?smaug

Comment 8

[Andrea Marchesini [:baku]]

Attachment: Bug 1621424 - Revoke popup token in timeouts at the first window.open - tests, r?smaug

Depends on D68590

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Edgar, you may have an opinion on the approach here.
See the patch and my comment there.

Comment 10

[Edgar Chen [:edgar] (PTO until 02/09)]

Commented on the Phabricator.

Comment 12

[:Gijs (he/him)]

What can we do to make progress here?

Comment 13

[Johann Hofmann [:johannh]]

Baku isn't currently working on Gecko stuff AFAIK and I'm just recovering from leave. I'd be interested in following up to this but realistically I'll have to leave the needinfo open for a bit.

I'll also bring this up with Paul to see if he has any cycles to look at it.

Comment 14

[Guilherme Keerok]

is this report eligible for the bug bounty program in the category "Persistent-DOS of browser across restarts or a DOS requiring reboot of user’s computer"?

Comment 15

[Guilherme Keerok]

also, because this open other possibilities to exploit xss in SOME Attack scenarios

Comment 16

[Johann Hofmann [:johannh]]

I think this is fixed now, maybe through the user activation changes in popup blocker?

Guilherme, in case you're still around, can you confirm whether this is still reproducible for you?

Comment 17

[:Gijs (he/him)]

(In reply to Johann Hofmann [:johannh] from comment #16)

I think this is fixed now, maybe through the user activation changes in popup blocker?

Guilherme, in case you're still around, can you confirm whether this is still reproducible for you?

I can still reproduce this from the jsfiddle link in comment 0 on macOS, beta 94. Things get blocked on Nightly, but also on Nightly 94 when I tried mozregression, so I think something nightly-only is helping here, but it's not clear what, and this is clearly not fixed yet for release/beta users. :-(

Comment 18

[:Gijs (he/him)]

Oops, PEBKAC - looks like I had allowed popups for jsfiddle on my main profile. 😅

Guilherme, in case you're still around, can you confirm whether this is still reproducible for you?

So this question stands, then.

Comment 19

[Edgar Chen [:edgar] (PTO until 02/09)]

(In reply to Johann Hofmann [:johannh] from comment #16)

I think this is fixed now, maybe through the user activation changes in popup blocker?

Yeah, I think this might be fixed after the popup blocker partly adopt the user activation changes, I will double check again.

Comment 20

[Edgar Chen [:edgar] (PTO until 02/09)]

I think this is fixed after the popup blocker starts consuming the user activation while opening a popup.
Lets close this. Guilherme, feel free to reopen it or file a new bug if you still reproduce this.