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

Steps to reproduce:

This is a browser locker attack.

1. Load attached sample in the latest version of Firefox.
2. Attempt to close the browser window or browser tab.

Actual results:

Browser is 'locked' with RAM used up at 100%. The user cannot normally close the window or tab.

This attack also uses what appears to be a new 'evil cursor' technique. The previous one was fixed in FF79 (CVE-2020-15654). I am attaching code to reproduce this defect.

Expected results:

Browser can be closed normally via the UI.

Firefox may crash after some time (memory issue?) and in some cases the entire machine will also crash.

Minimal reformatting, mainly commented out the two scripts to show the cursor issue.

Emilio: on my mac the fake cursor goes way above the "line of death" before switching back to the real cursor (seems fine on sides and bottom). This was supposed to have been fixed in bug 1445844. In a similar DOS scenario to this bug (originally) you thought the unwanted displacement was due to a busy content process and fixed that in bug 1648333. But with this attachment there are no scripts running and that shouldn't be the cause.

This is all what we've seen in similar reports. In addition to the offset cursor there's a script that creates the page contents and tries to go fullscreen and eat keystrokes. Appears to be made for all browsers (detection for Chrome, Opera, and Firefox specifically). Then there's a DOS part which is the pushState overwhelm (see bug 1314912). This consists of 51 obfuscated copies of

setTimeout(function() {
  setTimeout(function() {
    for (var idx = 0; idx < 1000000; idx++) {
      history[("pushState")](0, 0, "#"+idx.toString())
    }
  }, 0x64)
}, 0x64);

each copy has different loop count and timeout value. Most loops are ~1 million; the last 8 are ~10 million times.

The DOS part of this is a duplicate of bug 1314912. Leaving it open for Emilio to look at the cursor issue and figure out why that's not fixed. I tested on Mac, if that matters.

(In reply to Daniel Veditz [:dveditz] from comment #2)

Emilio: on my mac the fake cursor goes way above the "line of death" before switching back to the real cursor (seems fine on sides and bottom). This was supposed to have been fixed in bug 1445844. In a similar DOS scenario to this bug (originally) you thought the unwanted displacement was due to a busy content process and fixed that in bug 1648333. But with this attachment there are no scripts running and that shouldn't be the cause.

Can you clarify? It seems to be working as expected for me both on Linux and Mac. When blocking the deceptive cursor, then we switch to the next on the list, which in this case is crosshair.

Had to compress it to be able to upload it to bugzilla, so sorry for the watermark :)

Interesting... For me the cursor can reach the top of the tab strip before the real cursor shows up. I tried a fresh profile in case it's something I tweaked that I've forgotten, but that didn't make any difference. I'm on macOS 10.14.6 if you think that might matter. I guess if most people get what you do then it is fixed, but I don't know why my setup would differ.

For what it's worth this attack is primarily going after Windows users. Even though tech support scammers will target any platform, they tend to spend most of their effort on Windows.

As such (and this is what I tested), the browlock on Firefox 79 for Windows leads to a crash of either FF itself of the entire machine. More information in this tweet thread:
https://twitter.com/jeromesegura/status/1291456746859319297?s=20

Thanks

The lock/crash bit is pure resource exhaustion from the 100 million pushState calls, which flood the inter-process communication (IPC) between the sandboxed "browser" process and the parent process that has access to the history database. That part, sadly, we know all too well. I don't know why the rate-limiting approach in bug 1314912 stalled out and never landed.

Given Emilio's results on the same platform I tested I'll trust the overall fix for the cursor issue. If I figure out what I may have tweaked to cause my symptoms I'll file a separate specific bug -- I'm always getting tripped up by non-standard settings I've forgotten I've made.

Paul: I don't know where you are on your "eviltraps" work, but we're seeing increasing amounts of this technique in the wild. Would be great if you can work this into your plans (make the fix in public bug 1314912, I'm just needinfo-ing you here because it's a current example).

Thanks for the explanation regarding the resource exhaustion. Regarding the evil cursor part, are you saying it's already fixed in FF 79? Because in the latest Firefox for Windows (which is the intended target), the user still cannot close the browser window or tab which leads to the resource exhaustion problem.
The user has 2 solutions: taskkill the firefox process or close FF from the taskbar (right click, close). Neither of those are something the intended victims (older folks) know how to do.

Thanks Daniel! While a broader solution for IPC DoS would be best (Bug 1588509), I can see how we want to address the pushState issue specifically given that it's abused in the wild.
I'll have a look at the unlanded patches of Bug 1314912 and see if we can build on that.