Ask me anything!

Have a question you always wanted to ask Moonchild but never did? Now's your chance!
From 2026-03-08 to 2026-03-15 I'll be open to any question by the community, after which I'll provide answers.

Go here to participate: https://forum.palemoon.org/viewtopic.php?f=66&t=33222

TheRegister - Security hole that can crash any chromium-based browser

Off-topic discussion/chat/argue area with special rules of engagement.
Forum rules
The Off-Topic area is a general community discussion and chat area with special rules of engagement.

Enter, read and post at your own risk. You have been warned!
While our staff will try to guide the herd into sensible directions, this board is a mostly unrestricted zone where almost anything can be discussed, including matters not directly related to the project, technology or similar adjacent topics.

We do, however, require that you:
  • Do not post anything pornographic.
  • Do not post hate speech in the traditional sense of the term.
  • Do not post content that is illegal (including links to protected software, cracks, etc.)
  • Do not post commercial advertisements, SEO links or SPAM posts.
We also ask that you keep strongly polarizing topics like politics and religion to a minimum. This forum is not the right place to discuss such things.
Please do exercise some common sense. How you act here will inevitably influence how you are treated elsewhere.
User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1300
Joined: 2020-05-31, 04:33

TheRegister - Security hole that can crash any chromium-based browser

Post by andyprough » 2025-10-30, 23:05

This is an interesting new exploit that the chromium devs have apparently tried to ignore:
https://www.theregister.com/2025/10/29/ ... /?td=rt-3a

Some quotes from the article:
The flaw is due to the absence of throttling on document.title updates, so it essentially takes advantage of the fact that Blink doesn't limit resource consumption. ... Any web page could contain the malicious JavaScript code
One tab using 18GB of RAM (remember, Blink doesn't limit resource consumption):
The Register tested the code on Edge, and not only did it crash the browser, but it also locked up the Windows-based machine after about 30 seconds, and sucked down 18 GB of RAM into one tab.
The exploit in 3 simple steps:
First, in the preparation phase, the attacker pre-loads into memory 100 unique hexadecimal strings of 512 characters. It's "crucial" not to simply reuse strings because that reduces the attack's effectiveness, Pino explained.

Next, the attack executes in bursts of three consecutive document.title updates. Pino used a default configuration (burst: 8000, interval: 1ms), which means about 24 million updates per second are attempted, thus causing the browser crash.

Then in the third stage, the continuous updates saturate the browser's main thread, thus consuming massive amounts of compute and preventing it from processing other events. Between five and 10 seconds in, the browser's tabs will freeze, between 10 and 15 seconds, it will collapse or show a "page unresponsive" dialog box, and between 15 and 60 seconds into the attack, Chromium-based browsers will require forced termination.
I'm assuming Pale Moon would not be susceptible to such an attack. Neither Firefox nor Safari were. But all chromium-based browsers are open to the attack, and the bad news for them is that each chromium-based browser will likely require an independent fix. They probably can't just sit back and wait for Google to figure it out.

User avatar
RealityRipple
Keeps coming back
Keeps coming back
Posts: 937
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by RealityRipple » 2025-10-31, 01:16

We avoided something tangentially similar during the URL fragment navigation code work, but in the address bar, and having to do with stealing user focus and input rather than crashing.

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1149
Joined: 2020-11-03, 06:47
Location: Philippines

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by jobbautista9 » 2025-10-31, 03:32

I tried the proof of concept under SubWebView's Chromium 130, and yeah I can confirm that it quickly eats up a lot of RAM looking at the plugin-container process in Task Manager. The NPAPI plugin can also observe changes in its document.title, and therefore change the Pale Moon tab's own title, so Pale Moon is kinda affected by this if you have SubWebView installed and configured to have the offending website rendered by Chromium. But you know what's interesting? Despite Pale Moon also experiencing the rapid changes in document.title it never locks up the browser UI and I can still do stuff in other tabs (it does lock up SubWebView's own UI in that right-click doesn't bring up the context menu). Hell I tried to make it worse by having devtools' DOM inspector open so that more of the browser UI gets rapidly updated, and while it did make the browser a tiny bit slower it still didn't lock up (and when you consider the fact that our devtools is kinda dated and can struggle with very large DOM trees it makes it even more impressive). And since SWV's Chromium runs in single-process mode (which I suppose is necessary because I don't think you can do multi-process inside a plugin-container, and thank god Google has not removed it despite many attempts by short-sighted developers in the Chrome team trying to get it removed), it doesn't lock up the whole OS too.

Another win for single-process mode over e10s/multiprocess I guess! :thumbup:

By the way does anyone know of a simpler, cross-browser implementation of the PoC that doesn't look like it's larping the Matrix or whatever? When I tried running it natively (i.e. without SubWebView) and setup a site-specific user-agent override to pretend to be Chrome (since it intentionally doesn't want to run in non-Chrome by blocking with a warning overlay, like come on if you're gonna prove that non-Chrome is not vulnerable then let us run it!), clicking on the "Accept to continue" button doesn't do anything. I suppose the SubWebView workaround could be proof enough that we are not vulnerable (since the main Pale Moon browser process didn't take up much CPU or eat up RAM), but I'd still like to make sure. ;)
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1149
Joined: 2020-11-03, 06:47
Location: Philippines

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by jobbautista9 » 2025-10-31, 05:22

I was able to force the PoC to run natively by executing Brash.run({burstSize: 8000,interval: 1}); in the devtools web console (and quickly closed the devtools afterwards). It slowed down my main profile (which had plenty of add-ons which could be interfering with the script), but in a fresh profile it's manageable. Both of them didn't result in a quick meltdown situation with RAM (the fresh profile wasn't even able to reach 1 GB until I reopened the devtools which did make my browser slow down to a crawl). So while yeah it was able to slow my browser UI down, it's still far preferable than locking up the whole OS due to quick RAM exhaustion.

Anyway as I've noted in this GitHub issue I don't think Firefox (and its soft forks) is "not vulnerable". It did handle it better than Chrome when it comes to UI not hanging, but the RAM exhaustion is still too quick (not as quick as Edge did for me but can still be quick enough to lock up the OS on systems with less RAM than 16 GB).
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

User avatar
Moonchild
Project founder
Project founder
Posts: 38957
Joined: 2011-08-28, 17:27
Location: Sweden

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by Moonchild » 2025-10-31, 07:20

You know what I think happens here? multi-process IPC swamping the task scheduler. This is exactly the kind of thing I warned about in my write-up about e10s/IPC 8 years ago.
Why do I think this? Simple: changing the title requires a message to be sent from a content process to the UI through IPC. If you sufficiently flood the IPC protocol with messages, it will bring your browser to a halt in its entirety because you're basically DoSing the browser's internal communications.
This denial-of-service will almost certainly be exploitable with other UI-mirrored properties.
"There is no point in arguing with an idiot, because then you're both idiots." - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1300
Joined: 2020-05-31, 04:33

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by andyprough » 2025-10-31, 10:18

Moonchild wrote:
2025-10-31, 07:20
This denial-of-service will almost certainly be exploitable with other UI-mirrored properties.
Then this could be like the Spectre vulnerability to speculative execution in CPU's. Just like how Spectre was the first of many successful side-channel attacks, this could be the first of many exploits of multi-processor browser UI interprocess communication. This could be the beginning of the end for chromium.

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1149
Joined: 2020-11-03, 06:47
Location: Philippines

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by jobbautista9 » 2025-10-31, 10:24

Apparently this issue has been known by the Chromium team since version 49 (March 2016): https://issues.chromium.org/issues/41245417
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1300
Joined: 2020-05-31, 04:33

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by andyprough » 2025-10-31, 10:55

jobbautista9 wrote:
2025-10-31, 10:24
Apparently this issue has been known by the Chromium team since version 49 (March 2016): https://issues.chromium.org/issues/41245417
And look at this comment from yesterday on Issue 41246063 - they have known about this for years and how it could spread to other parts of the UI, and have already basically given up on solving it:
This a well-known issue already. We did a bandaid fix for pushState() (see all the dupes of issue 40080060), but sadly there are many many ways for a renderer to send IPCs to the browser, and pretty much all of them can result in some sort of DoS.

We can try to mitigate them individually here and there, but it's a losing battle unless we address issue 40086182.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1300
Joined: 2020-05-31, 04:33

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by andyprough » 2025-10-31, 12:02

Looks like this same basic bug was reported to google in 2014: https://issues.chromium.org/issues/40080060

The discussion on that issue shows that Malwarebytes was tracking the use of these exploits in malware by 2016, and they were known to already be abused on at least twitter and facebook to crash browsers in January 2016.

This comment from November 2016 shows what I think Google's response has been this entire time - do nothing and hope that Safe Browsing will catch enough of the abusive links to prevent too much damage:
I do not think we should get into a game of whack-a-mole (by rate limiting pushState), because there are plenty of IPCs the renderer could send to cause DoS in the browser. Finding some general approach seems required, and Safe Browsing should help block known cases in the meantime.

I agree that we should try to do something about this-- thanks kinuko@ for taking a look!

However, I don't understand why this is rated as a medium severity security bug according to our guidelines. That's not what our documentation says (because the architecture was never designed to prevent it):
https://www.chromium.org/Home/chromium- ... rity-bugs-

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1149
Joined: 2020-11-03, 06:47
Location: Philippines

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by jobbautista9 » 2025-10-31, 12:49

Moonchild wrote:
2025-10-31, 07:20
You know what I think happens here? multi-process IPC swamping the task scheduler. This is exactly the kind of thing I warned about in my write-up about e10s/IPC 8 years ago.
Why do I think this? Simple: changing the title requires a message to be sent from a content process to the UI through IPC. If you sufficiently flood the IPC protocol with messages, it will bring your browser to a halt in its entirety because you're basically DoSing the browser's internal communications.
This denial-of-service will almost certainly be exploitable with other UI-mirrored properties.
Btw I've borrowed your insights for this Hacker News comment on a submission linking to the PoC's repo: https://news.ycombinator.com/item?id=45771364
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

User avatar
frostknight
Keeps coming back
Keeps coming back
Posts: 918
Joined: 2022-08-10, 02:25

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by frostknight » 2025-11-01, 01:18

Everything is dumber in chromium browsers apparently... :P
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Say NO to Fascism and Corporatism as much as possible!
Also, Peace Be With us All!

User avatar
UCyborg
Keeps coming back
Keeps coming back
Posts: 774
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by UCyborg » 2025-11-01, 10:39

andyprough wrote:
2025-10-31, 10:18
This could be the beginning of the end for chromium.
What makes you think the next 9 years will be different from the last?

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1149
Joined: 2020-11-03, 06:47
Location: Philippines

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by jobbautista9 » 2025-11-01, 11:58

I just can't get my mind off this PoC, so I've done more experiments.

Just for the fun of it I've tried SeaMonkey, and surprisingly the UI remains fast and responsive there despite being single-process like us. A caveat though is that whenever the offending tab is focused on the memory usage will spike, but only up to 2 GB. The garbage collector frees up memory after that point has been reached. If you switch focus to another tab it gets even better: the garbage collector immediately frees up the memory and the script execution in the offending tab calms down. I'm suspecting their adoption of a multithreaded JavaScript runtime as part of Firefox 56 plays a role here. IIRC there is still some sort of IPC between threads, which would explain the memory usage. However since it's within the same process it's less expensive and blocking, which might've allowed the GC to act unlike in current Firefox. I am not an expert in this low-level stuff though so please take my words with a grain of salt.

However I've soon found that SeaMonkey is cheating a bit. You see, they have smooth scrolling disabled by default (unlike us), so when I enabled that and ran the Brash code again I definitely can feel SeaMonkey slowing down (even if I switch to another tab), and memory usage is now up to 3-4 GB. Strangely though I don't get the fast and responsive behavior in a fresh profile of Pale Moon with smooth scrolling disabled. It's a bit faster but not fast enough to be practically invisible like SM did.

Another interesting thing I found is the reason why my main PM profile struggled against Brash in contrast to a fresh profile: uBlock Origin (I'm using 1.16.6.1 from UCyborg's fork) somehow is the culprit of making the slowdown worse. It also makes my browser use much more memory than it should. In a fresh profile without add-ons the memory usage can sit around 100-200 MB no matter how long you run the Brash code, but install and enable uBlock in it and you can see the RAM jump to 400-800 MB... In SeaMonkey + uBlock it's better, but I did notice very short moments of lag even with smooth scrolling disabled (the memory usage is still worse than PM). With smooth scroll enabled the slow down is as bad as Pale Moon + uBlock (but still significantly worse in memory usage).

So these results pose some interesting questions:
  • Would I rather have a multithreaded JS runtime? Despite:
    • adding more complexity to the engine,
    • regressions, of which this experiment's result of increased memory usage and not playing well with smooth scrolling being examples of such,
    • and possibly bringing a few security risks: https://repo.palemoon.org/MoonchildProd ... ment-33749
    to get the responsiveness of SeaMonkey (as long as I have smooth scrolling disabled), or..
  • Would I stick with the simpler JS runtime Pale Moon has,
    • for less memory usage,
    • in exchange for reduced UI responsiveness when encountering offending sites rapidly updating UI-mirrored properties like document.title?
The latter seems the more sensible option (I'd rather have the browser hang in the worst-case scenario if it means not locking up the OS), but the former's advantage is surely tempting (not only because of the responsiveness but also because it kinda proves that you don't need multiple content processes or e10s to have a fast UI)... :coffee:
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1300
Joined: 2020-05-31, 04:33

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by andyprough » 2025-11-01, 13:58

jobbautista9 wrote:
2025-11-01, 11:58
Just for the fun of it I've tried SeaMonkey, and surprisingly the UI remains fast and responsive there despite being single-process like us
Be interesting to try this on something unique like Servo or Ladybird.
UCyborg wrote:
2025-11-01, 10:39
What makes you think the next 9 years will be different from the last?
Obviously as @jobbautista9 pointed out, Google has known about this and just buried their heads in the sand for at least 9 years now, so you are correct in assuming nothing may change. So maybe I should change my original statement to "the continuation of the shrug and yawn response by the big tech chromium collective". I mean, it's nothing to them but a conduit for transporting advertising to billions of human eyeballs. A rotating billboard that half of humanity carries in their pocket. A small piece of the giant global quadrillion dollar mind control game.

So maybe nothing will change.

Or maybe 9 years from now Pale Moon will be the most used browser on Earth and @Moonchild will displace Musk and Larry Ellison as the world's richest person. Hard to say, but definitely one of those two options.

User avatar
UCyborg
Keeps coming back
Keeps coming back
Posts: 774
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by UCyborg » 2025-11-01, 14:43

It's just that good sites won't attack your browser and presence of vulnerability doesn't mean much unless it gets in the way.

I could still do everything I need to online on Windows XP if I wanted to. Its holes don't mean much in the grand scheme of things.

But security propaganda is a strong one. In reality, 99,99% people don't understand these vulnerabilities and whether it effects them or their environment.

SeaMonkey is more responsive in general. I'd vote for faster JS runtime any day over delegating older functional hardware (khm,khm...AVX...cough,cough) to the garbage bin. Security, yeah, don't care.

User avatar
Moonchild
Project founder
Project founder
Posts: 38957
Joined: 2011-08-28, 17:27
Location: Sweden

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by Moonchild » 2025-11-01, 14:47

andyprough wrote:
2025-11-01, 13:58
Or maybe 9 years from now Pale Moon will be the most used browser on Earth and @Moonchild will displace Musk and Larry Ellison as the world's richest person. Hard to say, but definitely one of those two options.
I don't see that happening in this universe so it'll most likely be shrug and yawn and more ads in everyone's pocket.
"There is no point in arguing with an idiot, because then you're both idiots." - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1149
Joined: 2020-11-03, 06:47
Location: Philippines

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by jobbautista9 » 2025-11-01, 15:59

UCyborg wrote:
2025-11-01, 14:43
It's just that good sites won't attack your browser and presence of vulnerability doesn't mean much unless it gets in the way.

I could still do everything I need to online on Windows XP if I wanted to. Its holes don't mean much in the grand scheme of things.

But security propaganda is a strong one. In reality, 99,99% people don't understand these vulnerabilities and whether it effects them or their environment.

SeaMonkey is more responsive in general. I'd vote for faster JS runtime any day over delegating older functional hardware (khm,khm...AVX...cough,cough) to the garbage bin. Security, yeah, don't care.
Well, being a user of an unmaintained OS where you could do nothing to fix known vulnerabilities and have to instead mitigate is different from being a developer for a maintained browser. And in the latter case you would have to consider others' threat models that oneself wouldn't be dealing with.

If the security costs of a multithreaded JS runtime isn't as much as e10s and WebExtensions (both of which have holes that need to be constantly patched like each Mozilla security advisory), I might be more inclined to support it for the sake of performance. But I don't know if thar's the case since I'm not Moonchild who looks through restricted sec bugs in bugzilla...
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

User avatar
andyprough
Board Warrior
Board Warrior
Posts: 1300
Joined: 2020-05-31, 04:33

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by andyprough » 2025-11-01, 17:37

Is SeaMonkey really more responsive? I have my doubts, I've tried it many times and it does not do the job for me at all. I think what you may be noticing is that SeaMonkey with no extensions might feel slightly snappier than your regular Pale Moon profile loaded up with multiple extensions. That might be possible. But I'll wager that if you put Pale Moon with a fresh new profile and no extensions side-by-side with SeaMonkey you would have a difficult time finding any particular advantage to SeaMonkey.

If I was going to use something other than Pale Moon it would be Basilisk, which tends to run with a few mb lower ram on my systems.

User avatar
Moonchild
Project founder
Project founder
Posts: 38957
Joined: 2011-08-28, 17:27
Location: Sweden

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by Moonchild » 2025-11-01, 18:06

jobbautista9 wrote:
2025-11-01, 15:59
If the security costs of a multithreaded JS runtime isn't as much as e10s
It's not as much as e10s, but definitely significant, because making something "multithreaded" (kind of a misnomer here, actually -- what Mozilla did was move to a thread model for runtimes instead of controlling everything with the main event loop) that was designed from the ground up to work differently opens up the very real issues of code and data races, use-after-free/double-free etc. as well as making things a lot more complex and less efficient because a lot of needed mutex locking (with potential deadlocks there too). So no, it's certainly not something to take lightly.
There is something I could potentially work on, sort of following what Mozilla did but not necessarily restructuring everything, but that's certainly not something that's short-term or quickly implemented.

I'm also not so sure that it would make things more responsive; it's primarily a different approach that would make GCs a bit lighter (since it would make doing full GCs a rarity, if it's ever done anymore to begin with) so it may get the appearance of being more responsive but under the hood it would still have to do the same amount of work (and become more CPU heavy in normal operation, not these edge cases).
SO, it's definitely something to carefully consider before doing any work on.
"There is no point in arguing with an idiot, because then you're both idiots." - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
UCyborg
Keeps coming back
Keeps coming back
Posts: 774
Joined: 2019-01-10, 09:37
Location: Slovenia

Re: TheRegister - Security hole that can crash any chromium-based browser

Post by UCyborg » 2025-11-01, 19:35

andyprough wrote:
2025-11-01, 17:37
Is SeaMonkey really more responsive? I have my doubts, I've tried it many times and it does not do the job for me at all. I think what you may be noticing is that SeaMonkey with no extensions might feel slightly snappier than your regular Pale Moon profile loaded up with multiple extensions.
It is to me. Unless extensions are doing something crazy, they don't usually have an effect on how things on web page respond when you click them. Moonchild may not believe in benchmarks, but Speedometer 2.0's numbers correlate exactly in how things respond in real life in my experience. It doesn't cover video decoding and WebGL, but with general manipulations of elements on web page and interactivity in general, it's good at distinguishing performance profile of two browsers. At least on the same hardware.

Although WebGL content is driven by JavaScript code or Web Assembly, so the relative scoring of Speedometer may still applies. "May" because there could be differences due to ANGLE / no ANGLE / different build of ANGLE.

Regarding SeaMonkey, I can also tell the difference from just interacting with the settings dialog on Project VORAPIS' frontend on YouTube.

And even if you put fullscreen browser on my screen, I can tell Pale Moon from the others just by interacting with any phpBB forum. Sooo, I'm not buying Moonchild's opinion that web pages are terrible. Well, a lot of them are, but that's besides the point. It's not a big difference in this case, but for sensitive person, it's detectable.