1913000 - (CVE-2024-10464) Browser chrome freeze on history API

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Andrei Enache]

The browser chrome (mostly) freezes when busy loop updating the scrollRestoration string.

This is the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=1314912, but instead can be reproduced on Firefox 129 with the following slightly different setup:

while (1) {
  history.scrollRestoration = "auto"
}

The effect is the same, the browser chrome is mostly frozen, and the parent process seems to be affected.

I have reproduced on different operating systems. I assume this bug should be sec-low.

Comment 1

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

I guess nsHistory::SetScrollRestoration could use a CheckLocationChangeRateLimit check.

Comment 2

[Emma Zühlcke [:emz]]

Yes, we could cover that field as well. Most likely this IPC call causes the DoS: https://searchfox.org/mozilla-central/rev/e942f7bc56cd103bba86b396ddeba5b1ab04f1a4/docshell/base/nsDocShell.cpp#11544

There are many APIs which can be DoSed like that, not sure if this is worth fixing on a case-by-case basis. For the history interface we've done it before so I'm not opposed to it.

William, would you like to take this bug? See Bug 1314912 and comment 1 for context.

Comment 3

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

yeah, on IPC side there would be likely many similar cases.

Comment 4

[William Wen (:wwen)]

Yeah, I can definitely take this bug. I'll take a look later today.

Comment 5

[Emma Zühlcke [:emz]]

Thanks!

Comment 6

[William Wen (:wwen)]

Attachment: Bug 1913000 - Add more rate limiting to History interface. r=pbz

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8cee2583590d
Add more rate limiting to History interface. r=webidl,smaug,webdriver-reviewers,whimboo

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/8cee2583590d

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR128 approval when you get a chance. It grafts cleanly.

Comment 10

[William Wen (:wwen)]

Attachment: Bug 1913000 - Add more rate limiting to History interface. r=pbz

Original Revision: https://phabricator.services.mozilla.com/D221255

Comment 11

[William Wen (:wwen)]

Attachment: test.html

Test site for QA to verify bug

Comment 12

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Possible DOS slowing or crashing browser
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Open the test.html file attached in the bug, the browser chrome should not slow down or freeze
• Risk associated with taking this patch: Low
• Explanation of risk level: Rate limit is not aggresive, low potential for breakage. No breakage seen from rate limiting existing APIs
• String changes made/needed: No
• Is Android affected?: yes

Comment 13

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/4d095cdccd60

Comment 14

[Bogdan Maris, Desktop Test Engineering]

Using an old Nightly build from 2024-08-12 I get a OOM crash when using the attached testcase https://crash-stats.mozilla.org/report/index/6e8fd41e-64ce-4fb1-8d07-c93f70241018, verified that using latest Firefox Beta 132.0b7 and latest 128esr build from treeherder across platforms (Windows 11, macOS 13 and Ubuntu 22.04) the testcase does not crash anymore and it just displays the string "Welcome to My Simple jQuery Page" in the tab content.

Comment 15

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt