Unpatched Bug Can Crash Chromium-Based Browsers in Seconds (theregister.com) 24
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.
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 (Score:5, Funny)
So, a standard Firefox session in other words. /rimshot
Re:Interesting (Score:4, Insightful)
Re: (Score:2)
before Web 2.0, I could run 200 tabs on Chrome or FF in 16G RAM
Slot-shaming. (Score:2)
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.
An embarrassingly large number?
Do we need to start (memory) slot-shaming you for that tab count you got there, C-304?
Re:Interesting (Score:4, Informative)
>"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: (Score:2)
>"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: (Score:3)
>"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: (Score:2)
Especially front-end heavy websites are often very bad in releasing memory when they change the dom.
Eating more and more memory every time something changes.
Re: (Score:2)
... I don't actually know if it is Firefox or UBO.
Definitely FF. I believe I've seen it more often on sites that want to auto-update the page every so often. Usually it's the active tab, but not always. Last time it happened to me, IIRC I had a few Youtube tabs open, listening to each one before closing. Suddenly, the video stops about 5min in, controls within the tab were non-responsive, "xosview" showed a core pegged at 100% with others flickering too, "top" showed an an "Isolated Web Co" process taking like 200%. I killed FF, eventually my system retur
Re: (Score:2)
>"So YT does it, I've had news sites do it too."
Well, I have two or three Youtube tabs up in the mix, and very often with one playing for very long periods, and haven't seen that behavior. I don't use news sites very often, though (and never leave those up).
Most of my persistent tabs/windows are Slashdot, Hotmail, three different forum sites, a game, Yahoo mail, a few Youtube, sometimes a Rumble, often a Wikipedia, and then some misc ones that change a lot.
Re: Interesting (Score:2)
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.
'billions of browsers' (Score:2)
Re: (Score:2)
Hey, if running on billions is good enough for Java, it's good enough for Chrome and Chrome-likes.
Re: (Score:2)
What this article says while trying not to say it: Chrome and friends wield an unhealthy monopoly over the browser world, and a single bug can wipe most WWW users off the map.
This is not hyperbole, but a true statement of fact, and it's not good.
exploits what...?!? (Score:2)
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: (Score:2)
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:exploits what...?!? (Score:4, Interesting)
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 that people might be doing silly things with title. well that's silly being silly, and is exactly the case here: 24 million updates per second is extremely silly, probably not a "reasonable use case". it's an intentional attack.
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.
as you would expect, nothing about the dom is trivial. have a look at the specs to get an idea what setting document.title involves, and keep in mind that that's just the document, you still need to update the agent's user interface. you could indeed thrash cpu and ram with a tight loop of "script activity", which is why browsers monitor and police the script's main thread. however, chrome is failing to throttle the updates higher up and at that rate gets even its own main thread choked.
btw, your tone seems way too assertive and overconfident for the level of knowledge and understanding you are showing about the subject.
Re: (Score:2)
Tons of software, including well designed web pages, change their title to indicate you have unsaved changes.
Pretty much all multiplatform browsers (Score:3)
>"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 (Score:2)
... without a user-approved popup for things like games, simulations etc. that might require it.