1782661 - Hang when a page has a localstorage entry with a hex value

Status: VERIFIED FIXED

(DevTools :: Storage Inspector, defect)

Description

[xer0days]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

1- Browse any website you like
2- Open developer tools (F12) -> storage -> local storage
3- Change one of the entries to 0x41414141, otherwise add a new item and change its value to 0x414141

Actual results:

1- The Firefox browser will be dosed, increasing its memory and CPU usage
2- It tested on the latest version of the software, as well as on Windows 10,7, and MacOS Catalina 10.15.

Expected results:

Nothing!

Comment 1

[xer0days]

Attachment: screen-recording-firefox-dos_6EarF4M5.mp4

POC

Comment 2

[:Gijs (he/him)]

The exact hex value doesn't seem to matter (adding a value of 0x1 also hangs) and the hang only happens when the devtools storage inspector is opened. So this seems like something to do with the devtools bits here. As an attacker cannot force a user to open the storage inspector, and because this is a hang rather than some kind of exploitable crash, this doesn't seem especially severe.

Comment 3

[Julian Descottes [:jdescottes]]

The issue occurs when you actually try to click on the item in the storage inspector. Merely opening the storage inspector will not trigger it.
It seems the problem is within the vendored JSON5 library used in parseItemValue.

This library is only used by the storage inspector so this should not impact any other DevTools panel. Will investigate to see if the issue was fixed upstream.

As far as security goes, this could be used to as an anti-debugging measure by a website (see https://www.usenix.org/system/files/sec21-musch.pdf). But it requires clicking on the item so it's unlikely to be very efficient.

Comment 4

[Julian Descottes [:jdescottes]]

Profile: https://profiler.firefox.com/public/6n3j7ktdr22w3jh4tbfzr0ayns5tfvkzx4n4070/calltree/?globalTrackOrder=80w7&hiddenGlobalTracks=1w7&hiddenLocalTracksByPid=96398-0w4~96400-0~96406-0~96405-0~96403-0~96407-0~96404-0~96401-01&implementation=js&invertCallstack&thread=0&v=7

Comment 5

[Julian Descottes [:jdescottes]]

I confirm that updating to json5 2.2.1 fixes the issue https://github.com/json5/json5/releases/tag/v2.2.1

Related issue on the repository: https://github.com/json5/json5/issues/228
The fix was included in v2.1.3 while we are still on v.2.1.0. Compare view between v2.1.0 and v2.2.1 at https://github.com/json5/json5/compare/v2.1.0%E2%80%A6v2.2.1

The list of changes seems relatively small, should be straightforward to update.

Comment 6

[Julian Descottes [:jdescottes]]

Attachment: Bug 1782661 - [devtools] Update json5 vendored library to v2.2.1

Compare https://github.com/json5/json5/compare/v2.1.0%E2%80%A6v2.2.1

Comment 7

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

[devtools] Update json5 vendored library to v2.2.1 r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/30d2983176bd8f44a9e3c4d6f6543118ef4a8a1e
https://hg.mozilla.org/mozilla-central/rev/30d2983176bd

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox104 to wontfix.

For more information, please visit auto_nag documentation.

Comment 9

[Julian Descottes [:jdescottes]]

Forgot to set this, but I don't think it's worth uplifting. This is not a recent regression, and I don't really think it qualifies as a security issue here.

Comment 10

[Daniel Bodea [:danibodea]]

I've reproduced the issue in Release v104.0.1 and verified the fix in Beta v105.0b7 and Nightly v106.0a1 on Windows 10, Mac OS 11 and Ubuntu 22.