New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 597012 link

Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue 598125
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 598125



Sign in to add a comment

Investigate possible memory leak by repeatedly changing document.title

Reported by maarkris...@gmail.com, Mar 22 2016

Issue description

Chrome Version: 49.0.2623.87
OS: Windows 10 Pro

URL (if applicable) where the memory bloat occurred:
http://goth06.xyz/test (it's my website, my folder, only to show you, and test on my PC)

Can you reproduce this memory bloat?
Yes, everytime.
It's a few row of JavaScript code:
<script>
    while(true)
    {
        document.title = "Test1";
        document.title = "Test2";
    }
</script>
When someone opens the webpage, it will change its title in an infinite loop. This cause both the processor, and the memory usage will go up. About a minute after opening the script, RAM is full, and I can't even handle my computer.(Using about 2++ gigabytes of RAM, and many percent of processor) I had to reboot my computer to use it again.
So its critical in many respects.
It also works on Chrome Android version! (Chrome will freeze)

What steps will reproduce this memory bloat (or if it's not reproducible,
what were you doing until then)?
(1) Implement this JavaScript code into a HTML file
(2) Open it in Chrome (all versions)
(3) Check out what happens.

 
bug.php
187 bytes View Download
Components: UI>Browser>TabStrip Blink>JavaScript>GC
Labels: Stability-Hang Performance OS-Android OS-Chrome OS-Windows
Summary: Rapidly changing window title hangs browser process and leaks memory (was: Memory and CPU usage bug, JavaScript (both on Chrome PC and Android version))
The test code hangs not only the renderer, but the entire browser. On my Chrome OS machine it made the entire thing unusable, I had to hard restart.

I understand why it's interacting with the browser process - it has to change the title. But it does seem like we don't want random code on the internet to bring down your entire machine.

I imagine the memory leak is because GC can't get a word in edgewise while this is going down. That may be unavoidable.
Labels: -OS-Android -OS-Windows -Pri-3 -OS-Chrome ReleaseBlock-Stable M-51 OS-All Pri-1 Type-Bug
Status: Untriaged (was: Unconfirmed)
Blockedon: 598125
Summary: Investigate possible memory leak by repeatedly changing document.title (was: Rapidly changing window title hangs browser process and leaks memory)
I filed issue 598125 to throttle document.title updates. Once that's resolved, we can investigate whether it's causing a leak. Updating the title (again) to reflect that.
Cc: rsch...@chromium.org
Why is this a blocker? This seems like a synthetic DOS use case?
Cc: abodenha@chromium.org
abodenha, please take a look at the question in 5
Labels: -ReleaseBlock-Stable
It's a bug with potential for abuse which has now been disclosed since this bug isn't restricted.

It's borderline. I don't see much value for an attacker other than malicious mischief. I'm removing the blocker label tho it would be good to have someone familiar with the GC or tabstrip take a look soon.

Simple solution could be to throttle requests to set the title.  Possible flow:
1: If a page requests to change title, change it.
2: If additional requests come in within 1s to set the title, cache the request.
3: After 1s from the last applied change take the most recent request and apply it.

I'm sure there would be consequences to figure out, but it seems like allowing a page to hang things by thrashing the title is unwise.


I understand what you say, but i'm sure that there are ways to use it by a clever attacker.
For example, some of the present ransomware viruses after infecting the PC needs rebooting, and then actives. These can be deactivated and removed before rebooting, but if it is done, it becomes hard to remove, and get the files back unharmed.
By this script, the attacker can force user/PC to reboot instantly after infection, so the attack is done easily.
Cc: u...@chromium.org
Labels: -Pri-1 Pri-3
Status: Available (was: Untriaged)
Setting this bug to the same priority as the fix for the title updates.
Project Member

Comment 10 by sheriffbot@chromium.org, Apr 21 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Mergedinto: 598125
Status: Duplicate (was: Untriaged)

Sign in to add a comment