Unpatched Bug Can Crash Chromium-Based Browsers in Seconds

A critical security flaw in Chromium's Blink rendering engine can crash billions of browsers within seconds. Security researcher Jose Pino discovered the vulnerability and created a proof-of-concept exploit called Brash to demonstrate the bug affecting Chrome, Edge, OpenAI's ChatGPT Atlas, Brave, Vivaldi, Arc, Dia, Opera and Perplexity Comet.

The flaw, reports The Register, exploits the absence of rate limiting on document.title API updates in Chromium versions 143.0.7483.0 and later. The attack injects millions of DOM mutations per second and saturates the main thread. When The Register tested the code on Edge, the browser crashed and the Windows machine locked up after about 30 seconds while consuming 18GB of RAM in one tab. Pino disclosed the bug to the Chromium security team on August 28 and followed up on August 30 but received no response. Google said it is looking into the issue.

Interesting

[93 Escort Wagon]

... while consuming 18GB of RAM in one tab

So, a standard Firefox session in other words. /rimshot

Re:Interesting

[ShadowRangerRIT]

checks current RAM usage Almost precisely 1 GB from all Firefox tabs put together (seven loaded and an embarrassingly large number of unloaded tabs I'll probably ignore for a few years before cleaning them up by the thousand). uBlock Origin and uMatrix probably reducing the load a bit by blocking all the ads. Chrome is no better at this (and worse at the ad blocking), I really don't get why people are so down on Firefox memory usage.

Re:

[haruchai]

before Web 2.0, I could run 200 tabs on Chrome or FF in 16G RAM

Re:

[markdavis]

>"So, a standard Firefox session in other words. /rimshot"

To be funny, there has to be some underlying truth or irony involved. But in this case, there isn't either. Firefox memory usage is pretty consistently lower than Chrom*.

Re:

[kbrannen]

>"So, a standard Firefox session in other words. /rimshot"

To be funny, there has to be some underlying truth or irony involved. But in this case, there isn't either. Firefox memory usage is pretty consistently lower than Chrom*.

The vast majority of the time, you're correct. However, from time to time I have [a Linux] desktop FF just go crazy where a tab suddenly starts to eat RAM, taking multiple GB and just holding a core hostage at 100% usage. If I'm lucky, I can figure out which tab it is and close it ... FF usually lets me do that but not always. Sometimes the only recovery is to tell the window manager to shutdown FF, where the GUI will go down quickly but "top" will show the sandbox engines running for another 30s or so befo

Re:

[markdavis]

>"so my guess is a memory leak is triggered after FF runs for a few days."

I am sure that is possible. But I keep at least two windows and 12 tabs open with Linux Firefox running for several weeks at a time without encountering any problems. Once in a blue moon I will have some type of site that causes high CPU/memory. When that happens, I don't actually know if it is Firefox or UBO.

Re: Interesting

[drinkypoo]

Desktop Firefox is great. Maybe you meant mobile Firefox, which has had terrible unpatched memory leaks in the JavaScript implementation for years and years. I have to kill Firefox several times a day on my phone. On my desktop it typically works fine without runaway memory use until I reboot for some other reason.

Take Two Interactive

[kurt_cordial]

I told my doctor I couldn't speak Spanish. He said don't speak Spanish.

'billions of browsers'

[Fly Swatter]

Damn, that's a lot of hyperbole. Like billions.

Re:

[Junta]

Hey, if running on billions is good enough for Java, it's good enough for Chrome and Chrome-likes.

exploits what...?!?

[ffkom]

exploits the absence of rate limiting on document.title API updates

That is not the root cause. There is no reason in the first place to allow a web page to change its title while being displayed. I for one have never seen such feature being used for anything useful. And then, even if you implement such feature, there is no reason why it should consume any more CPU or RAM resources than any other "script" activity to change other parts of the displayed document.

Re:

[test321]

There is no reason in the first place to allow a web page to change its title while being displayed.

Applications change the title to update with what they are doing. The Microsoft e-mail client changes the title on-the-fly to the name of the IMAP folder you're browsing. Maybe it can update it as well when you have new mail, or things like that. I would say, same thing as a CLI application that updates the title of an xterm window to inform of the progression of the CLI task.

Re:

[znrt]

There is no reason in the first place to allow a web page to change its title while being displayed. I for one have never seen such feature being used for anything useful.

so if you can't imagine a useful reason means nobody else should? document.title has been in the spec for more than 25 years, and it clearly states that the element needs to be changed both in the document's "head" section's "title" element and in the user interface (tab/window title). that's for a reason, namely that (surprise! surprise!) there are indeed many very valid use cases for it. documents are dynamic, and the title is a perfectly reasonable element to reflect that status.

that's notwithstanding th

Pretty much all multiplatform browsers

[markdavis]

>"A critical security flaw in Chromium's Blink rendering engine can crash billions of browsers within seconds."

Yes, all multiplatform browsers, except Firefox. Browser non-diversity is a serious security, stability, and freedom threat.

So, limit ALL UI modifying calls to 60fps

[ArghBlarg]

... without a user-approved popup for things like games, simulations etc. that might require it.