Remote Stack Overflow Vulnerability (DoS)
Reported by
ali.wami...@gmail.com,
Jan 29 2018
|
||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Steps to reproduce the problem:
Allows remote attackers to cause a denial of service (application crash) resulting in stack overflow via nested calls to the window.print javascript function.
<html>
<title>Remote Stack Overflow DoS PoC</title>
<body bgcolor="#50708C">
<center>
<p><font color="#e3e3e3">Remote Stack Overflow DoS PoC</font></p>
<button onClick=crash()>Execute!</button>
</center>
<script>
function crash(){
window.print();
crash();
}
</script>
</body>
</html>
What is the expected behavior?
What went wrong?
i have added a video poc
Did this work before? N/A
Chrome version: 64.0.3282.119 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
,
Jan 30 2018
ali.wamim.khan@ Thanks for the issue. Able to reproduce this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Stable 64.0.3282.119 and Canary 66.0.3334.0 by following the below steps. 1. Launched Chrome and opened html page which has the above given code. 2. Clicked on the Execute button and clicked on Cancel button on the print preview page. Instead of the html page, the print preview page keeps coming up as in the attached video. As this behavior is seen from M60 chrome builds, this is a Non-Regression issue and marking it as Untriaged for further updates from Dev. Thanks..
,
Jan 30 2018
Should printing consume a user gesture?
,
Jan 30 2018
,
Jan 30 2018
Consuming user gesture is a possibility, depends on if the print window currently requires one or not and if it would be "shared" with the page or not. But I think there must be other (simpler) ways to avoid re-entry to window.print(). The core problem is that window.print(); window.print(); opens two overlaid print dialogs, which looks insane.
,
Feb 1 2018
I think that this is not a binding issue, so remove Blink>Bindings. Feel free to add it back as needed.
,
Jun 6 2018
,
Jul 31
I'm not sure there's much we can do here. If I remove window.print() and replace it with window.alert('hi'), we have the same type of problem. If we just have crash() call itself, the JS program still infinite loops. The user's defense in these cases is to just close the tab.
,
Jul 31
User gesture detection does not seem helpful here, since the user clicked on the button, and all subsequent calls to crash() are part of that single click.
,
Jul 31
I'd personally vote for WontFix. My philosophy for things like alert() is that as long as it doesn't block the user from switching away, and the user can close the abusive tab, then we've done all we can, given the philosophy of the web to give the contents of the tab over to the foreign server. OP, can you clarify "vulnerability"? You claim an "application crash". If you indeed got Chrome to crash, please go to chrome://crashes/ and let us know what the crash ID is. Given that the recursion is in the renderer, I don't see this as being able to cause a browser crash. Given the size of a stack frame, I doubt it could even crash the renderer.
,
Aug 2
OP: If you can actually get a crash here, please re-open this bug and provide the crash information. Otherwise this is just user harassment for which the user can close the tab. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by krajshree@chromium.org
, Jan 30 2018