Chromium Browser DoS Attack via Document.title Exploitation | Hacker News Reader

Chromium Browser DoS Attack via Document.title Exploitation

github.com

14 pointscroes12 comments

Calling most APIs in a loop will eventually cause the browser to struggle or eventually crash. What is novel here? Repo looks to be entirely AI generated spam

Think you might be right, while reading through the README, I noticed some common LLM pattern words.

Also, some sections of the README completely read as generated by an LLM.

Well, Firefox and webkit browsers (Safari and friends) are all apparently not affected so it does appear there's something here.

I can’t think of the wording right now but generally JS trying to crash the browser would say something like this page is taking a long time, do you want to wait. Something like that. In this case the browser just crashes.

It does seem like it’s full of AI. The Attack Scenarios are very suspicious.

Is it some sort of "hacker" thing to use hexadecimal numbers even in small for loops?

> for (let i = 0x0; i < 0x3; i++) { document.title = t + i; // Each burst performs 3 sequential updates } this.counter += 0x3;

I suppose the thing is AI generated anyways. Oh well

"Hey, look at me, I'm using the hex 3, not the boring old 3 you plain people know..."

This screams AI generated and you can do this in thousands of ways.

I remember back in the day you could just use the alert function in a while(true) loop and that would be enough to render Internet Explorer unusable :)

Ha, back then they were native OS dialogs. And one would block the whole window, even when IE6 gained tabs.

This is as much of a DoS as an unterminated while loop is a DoS, is it not?

No, when you run something like <script> while(true) {} </script>, it will only freeze the tab where you ran it, the browser UI and other tabs will still be responsible and usable. When you run this DoS, it makes the entire browser unusable, and exhausts your system memory, eventually crashing the entire browser.

This is a very old problem, known since Chrome 49: https://issues.chromium.org/issues/41245417, https://issues.chromium.org/issues/41246063

Simply a consequence of multi-process' inter-process communication (IPC) swamping the task scheduler. 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.

Single-process browsers (e.g. Pale Moon) and browsers that have previously been designed primarily with a single-process model in mind and only adopted multi-process later (Firefox, Safari) would've handled this better by at the very least not locking up the browser and eventually the OS with a runaway meltdown in memory allocation.

To test this theory I've forced the Brash code to run with `Brash.run({burstSize: 8000,interval: 1});` in the devtools console. Why the PoC author decided to arbitrarily restrict the running the PoC only to Chrome-based browsers, I don't know. If non-Chrome truly is not vulnerable we should be able to verify that for ourselves.

In a fresh profile of Pale Moon without add-ons (and immediately closing the devtools afterwards) the UI does slow down but it's still usable (and therefore the offending tab can be closed even after a while). If you never reopen devtools in the offending tab the memory never even reaches 1 GB. In the worst-case scenario where the browser would hang (which could happen if you try to open up devtools in the offending tab for example), the memory allocation doesn't get instantly out of control, and the OS will recognize that it's hanging and let you close it.

In Firefox the UI is still working somewhat but memory allocation is faster than Pale Moon (but a bit slower than Chrome). Memory becomes manageable though when you switch focus to another tab; it no longer allocates more memory and the garbage collector was able to free up memory in the offending tab's content process with the JavaScript engine no longer blocking it thanks to the said content process being suspended in the background. However the main UI process will still hold a lot of memory unless you switch back to the offending tab for the garbage collector to recognize it needs to free up memory there. And if you close the offending tab before that you get yourself a memory leak, i.e. the memory allocated by the UI process will never go away, at least until you rerun the Brash code again (where the garbage collector will then recognize there is memory to be freed in the UI process).

I don't know about Safari, I have no Apple device to test it with unfortunately.

Reply on news.ycombinator.com