Please supply the "Uploaded Crash ID" crash details from the chrome://crashes tab.

In general, Denial of Service issues are treated as reliability issues, not security issues.

Thank you for the reply. I have a couple of good reasons to believe that this could have an impact on security based on my current research. I could be wrong, but I will update this thread in a few days with what I have and the crash reports.

Cheers

Is there some reason you cannot share a crash ID sooner?

I lean towards removing this from the security queue as per https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#TOC-Are-denial-of-service-issues-considered-security-bugs-

I'm adding "Needs-Feedback" label for now.

Next sheriff, please feel free to remove security labels if an additional information regarding security implications is not be provided.

Hello, 

I just did a bit of experimenting and found a more severe version of this bug. I've uploaded the script to http://ec2-18-220-218-135.us-east-2.compute.amazonaws.com:3003

Here is the relevant part from that script

```html
<script> function newWindow() { window.open('javascript:for(i=0;i<1000000000; i++) { console.log(4) }') }</script>
```

This is more severe in that it eats up about 1GB of memory (out of chrome process) in about 10-15 seconds on my machine. 

[In response to comment 3]

I cannot provide a crash ID because chrome doesn't crash. The "Page Unresponsive" dialogue window opens up, but it's unresponsive too. The only way to stop the process would be killing the chrome process from outside the chrome environment (kill command or system monitor tool etc.) or it ultimately results in the whole system being `thrashed`. I will attach a video along with my next comment so that makes more sense. 


[In response to comment 4]

In my opinion, any bug that doesn't crash the browser, but 
1. Makes the browser totally unresponsive
2. Eats memory until you have no more or until you forcefully kill it with side effects*

is more severe than a DDOS attack in the severity of things. I might be taking sides here. You guys are the experts. :)

However, on a serious note, I've found an instance of security implication that I don't know how to reproduce right now. That's the reason I was asking for more time.

Thank you for providing more feedback. Adding requester "mmoroz@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the additional information.

I wonder if you have any suggestions regarding how we can fix that issue. JS provides lots of opportunities (e.g. to do something in a infinite loop), we obviously cannot block these parts of the JS language.

For this particular testcase, the browser indeed became unresponsive for some time, but after that it started to work properly for me.

Let me put "Needs-Feedback" label again, so the bug won't show up in the security queue for some time until you update it. If you manage to get any security implication out of this issue, please update the bug with the details. Otherwise, we'll remove it from the security queue sometime later.

Thanks for trying the link. Sure, please go ahead and add the label (I am assuming you haven't added it already)

Here is the video that I promised I'd attach for the above test-case. It shows how the "Page Unresponsive" window ends up being not so useful. The chrome process crawls memory as expected. If I had waited, it would've finished up the RAM on my machine. 

About suggestions, this might sound silly and I apologize if it does because of my limited knowledge of how chrome's working. However, I've detailed what I know already. 

My particular concern is about chrome, or the broker process eating up memory. If a website executes a console.log() infinitely, 'and' if the DevTools is open for that particular tab, then => The broker process is all responsive and the browser is responsive and only that particular tab is effected. This is okay AFAIK.
 
If the DevTools is hidden, then instead of the Renderer process, broker process is the victim. If the loop is infinite, the broker process alone eats up all my memory (goes up to 5.6GB) and I'd have to force restart. 

That might not be particularly helpful, but that's only what I've got.

PS -- If it started working properly for you after a while, that might be because you're on a good machine and I didn't put an infinite loop there. Haha :)

Cheers and have a good day!

Deleted: Test4.mp4 5.5 MB

	Test4.mp4 5.5 MB View Download

Thank you for the additional information! Distinction with and without DevTools sounds interesting.

I'm adding "Needs-Feedback" and looking forward to an update regarding security implications :)

Agree with #4 and #7. Inclined to mark it as non-security issue. 
I'll come back to this issue once the reporter provides more reasoning of security implications.

Change issue type from Bug-Security to Security per #4 and #7.

Hello, I have a question that the FAQ doesn't answer and pardon me if this ain't the right place for this discussion. I would however appreciate if someone could clarify/answer this via email or some other means because I am not entirely sure where to ask this.

How would you differentiate between a Denial of Service and memory corruption? For instance, here is an old security bug I found from the Severity Guidelines Page --  Bug 455735 : Memory corruption in the browser process that requires specific user interaction, such as granting a permission that crashes the browser, and is of medium severity. Isn't that a peculiar case of DoS too?

I am curious about where to draw the line.

Thank you for providing more feedback. Adding requester "mmoroz@google.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

>> How would you differentiate between a Denial of Service and memory corruption?

Those are different things.

"Memory corruption" is a generalized name for a class of software errors: https://en.wikipedia.org/wiki/Memory_corruption

"Denial of Service" is a generalized name for an impact of some error or an action: https://en.wikipedia.org/wiki/Denial-of-service_attack


 Bug 455735  is about accessing the memory out of bounds of an allocated buffer. That is a memory corruption error. That particular bug can be exploited by an attacker to read / modify a memory that shouldn't be accessible by them (Medium severity: https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md#medium-severity).

So, the consequences can be more dangerous than Denial of Service.

Thank you Max for that clarification. That perfectly answered my question and consequently, I have a better idea of what sort of security bugs to look out for now. Cheers.

I'm considering closing this as WontFix. All it does is puts pressure on the IPC / mojo channel, same can be achieved via numerous existing JS APIs. In this case it is FrameHostMsg_DidAddMessageToConsole.

Might be worth addressing on the general browser scheduling level.

Re #17: Beyond the unresponsiveness claim, there's also a claim here that the browser memory consumption rises without limit. Is that not the case?

Other Mojo APIs subject to this form of abuse have introduced a variety of rate-limiting mechanisms (e.g. see  Issue 394296 ); those might make sense here if this vector ends up getting abused by the tech-support-scammers?

@elawrence: the fix you refer to states "This is not the long-term fix to IPC flooding that we need". It is rather a temporary plug than a browser scheduler  fix. Compromising the renderer works around it entirely as well. I would not want ad hock fix like this in DevTools and other places until there is an urgent need for the fix / evidence of abuse.

 Issue 793590  has been merged into this issue.

Closing this as won't fix - I don't think we want to special case console IPCs and mitigate it locally.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot