DOSing IndexedDB API calls will freeze the browser
Reported by
cgerv...@camcloud.com,
Jul 7 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Open the included html page 2. Run the code by clicking "I consent" button on the page 3. Your browser will become unresponsive in the tab, for a period of time. This can be extended to cause effectively a Denial of Service attack on the tab, once consent is given try to do anything on the page (ie, select text, scroll, etc), it will fail to respond What is the expected behavior? Theory is, it should throttle or rate-limit the storage requests to prevent a crash What went wrong? It did not throttle or rate limit, and ultimately crashes the browser. This effects the major three browsers (Chrome/Chromium, Firefox, Edge), there should be some sort of rate-limiting to throttling in-place to prevent a crash attack Did this work before? No Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: N/A
,
Jul 7 2017
Can you supply the ServerID of the crash from chrome://crashes ? We do not track DoS-only issues as security bugs, so this will help us understand exploitability. For DOMStorage, we deliberately crash the tab if an unreasonable number of storage actions are attempted; I don't know if IndexedDB has a similar protection. With 64bit Chrome 61.0.3150.1, I'm not able to reproduce a tab crash; the browser becomes unresponsive for under a minute, then behaves normally.
,
Jul 7 2017
Crash ID a7d2f121-d8ce-42ec-9943-4a96564f494e Local Crash ID 016e9961-a432-4662-9310-81f4bebd4d5b Crash report captured on Friday, July 7, 2017 at 8:41:38 AM (upload requested by user, not yet uploaded) Local Crash ID 7797d8d0-db51-4faf-8e49-4bbfd283fba2 Crash Report ID 87e4d518b8000000 (Local Crash ID: 1838911c-b1cf-4f0a-8fca-cc75dc0f4552) Try this file, I updated it to crash the entire browser instead of brief unresponsive.
,
Jul 7 2017
If you open task manager while running it (on Windows) you'll see the RAM and CPU usage spike as well, while the browser is non-responsive, and doesn't deliberate crash the tab (or, prompt to) for a few minutes.
,
Jul 7 2017
I agree with elawrence@, we generally don't treat these as security bugs. I'm inclined to mark it as regular bug and let component owner to decide how to proceed from here. elawrence@, WDYT?
,
Jul 8 2017
It can be throttled to make it so Chrome doesn't cause the deliberate tab crash, while still eating CPU/RAM up, which eventually when it exhausts all the ram and CPU the machine will cease function as it's eaten all available resources
,
Jul 8 2017
,
Jul 8 2017
Some observations using consent.html from c#5. * 32-bit Chrome 61.0.3141.7 dev. For some reason it didn't display Wait/Kill at all and [expectedly] crashed entirely. Crash Report ID af605aacb8000000 Stack trace shows IndexedDB -> LevelDB -> malloc -> NoMemory exception path. Obviously the related code should be fixed to crash the tab before depleting main process memory. * 64-bit Chrome 61.0.3152.0 canary. Crashes only 1 tab. Apparently because there is a hardcoded limit for a tab process at 3.5GB. * The "Wait / Kill" dialog could display the current CPU & memory usage updated each second. Currently it's not obvious to a user that there's an unrecoverable problem. Seeing the memory grow past 1GB in less than a minute would be more obvious. This warning can also be displayed when the tab memory usage grows to 2GB (once).
,
Jul 10 2017
dmurph@, pwnall@ - please take a look We've put some rate limiting in place already but we know it's not comprehensive.
,
Jul 10 2017
Issue 740351 has been merged into this issue.
,
May 15 2018
,
Jan 3
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by cgerv...@camcloud.com
, Jul 7 201716.9 KB
16.9 KB View Download