Open Bug 1644767 Opened 4 years ago Updated 3 years ago

DoS using shared workers and on-connect firefox

Categories

(Core :: DOM: Workers, defect, P3)

Product:
Core
Component:
DOM: Workers
Version:
77 Branch
Platform:
Desktop
Windows 10
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox85 --- affected
firefox86 --- affected
firefox87 --- affected

People

(Reporter: u635660, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

WebSocket_browser_crash_repro.html
(deleted), text/html
Details
Attached file WebSocket_browser_crash_repro.html (deleted) —

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

Steps to reproduce:

steps to reproduce
open WebSocket_browser_crash_repro.html in firefox

Firefox starts hanging and becoming unusable

Actual results:

firefox started becoming unstable

Expected results:

it should not start hanging and becoming unstable

Component: Untriaged → Security
OS: Unspecified → Windows 10
Hardware: Unspecified → Desktop
Severity: -- → S2
status-firefox77: --- → affected
status-firefox78: --- → affected
status-firefox79: --- → affected
Priority: -- → P2
Summary: dos using service workers and on-connect firefox → dos using shared workers and on-connect firefox
Component: Security → DOM: Workers
Product: Firefox → Core
Severity: -- → S2
Priority: -- → P1

:jstutte could you review the priority/severity for this bug?

Flags: needinfo?(jstutte)

Hi Eden, I assume it is less scary than P1 suggests here?

Flags: needinfo?(jstutte) → needinfo?(echuang)
Flags: needinfo?(echuang)
Priority: P1 → P2

Hi,
I am able to reproduce the issue in latest Nightly 87.0a1 (2021-02-08), Beta 86.0b7 and Release 85.0.1 using Windows 10. Changing the flags and the status accordingly.
Thanks.

Status: UNCONFIRMED → NEW
status-firefox85: --- → affected
status-firefox86: --- → affected
status-firefox87: --- → affected
Ever confirmed: true
Summary: dos using shared workers and on-connect firefox → DoS using shared workers and on-connect firefox

So on my machine this causes the CPU to spin 100% and memory of Firefox slowly increasing, but while this happens the rest of Firefox remains quite responsive in the sense that I can close the affected tab without problems and after a while things turn normal. Given that there are many ways to OOM and waste CPU cycles via Javascript, I think we can lower the severity here, too. However, it seems there is no doorhanger for the user that informs about a blocking script in this case.

Severity: S2 → S3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: