DoS/Crash repeatedly adding to open select widget
Reported by
cris...@gmail.com,
Jan 1
|
||||
Issue description------------------------- VULNERABILITY DETAILS Clicking select elements without the multiple attribute triggers a native display select widget. In Chrome the nodes inside the select element can be modified even when the native widget is open, resulting in unchecked growth of native widget. The exploit below simply doubles the number of the select's nodes as quickly as possible. The result is Chrome becoming unresponsive on my iMac with 16 Gb RAM and Chrome Helper process' memory usage growing to use all memory over the course of a few minutes. Neither the tab nor the browser can be closed. Tested in latest stable chrome on OSX and Android. On Android, it is possible to close the tab if you act before it runs out of memory. VERSION Chrome Version: [71.0.3578.98] + [stable] Operating System: [macOS 10.14.2 (18C54), V8 7.1.302.31] REPRODUCTION CASE Attach HTML file. Simply access this file with Chrome, and click on the select element, to reproduce. FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [browser] Crash State: [browser completely unresponsive, Out Of Memory (Chrome Helper)] Client ID (if relevant): [NA] CREDIT INFORMATION Externally reported security bugs may appear in Chrome release notes. If this bug is included, how would you like to be credited? Reporter credit: [Cris Stringfellow @ Dosyago Corporation]
,
Jan 2
,
Jan 3
Able to reproduce the issue on reported chrome version #71.0.3578.98 and latest chrome #73.0.3660.0 using Mac OS 10.14 by following steps as per comment#0. Note: Issue is not seen on Linux and Windows The behaviour is observed from M-60(#60.0.3112.113) builds. This is a non-regression issue hence marking it as untriaged and requesting someone from the dev team to look into the issue. Thanks.!
,
Jan 18
(4 days ago)
I'm not sure if we actually care to guard against a bad webpage taking up memory, it's always possible for a renderer to consume memory. This doesn't imply a security concern for users, and the solution is to not do this in the webpage. |
||||
►
Sign in to add a comment |
||||
Comment 1 by tsepez@chromium.org
, Jan 2