SaveFileResourceHandler::OnReadCompleted doesn't apply any backpressure to the request |
||||
Issue descriptionSaveFileResourceHandler::OnReadCompleted is called when the request associated with the handler completes a read. It posts a task to write the data to a file and continues with the request. If file writing is slow and resource reading is fast and the resource is large (which could be achieved with a hand crafted gzip payload + potentially several gzip content-encodings in series), this could conceivably be used as a DOS attack on browser memory. Note that this only happens in response to user request (through Save Page As ...). Lukasz: Would you be willing to speak to whether or not this could be done by an evil site without the gzip bomb being loaded in the page load preceding the SavePage (and presumably crashing the renderer)? I'm imagining loading JS that changes subresource references, but I don't know what protections exist or don't exist in the renderer against that. (I'll remove the RVG if this seems likely to crash the renderer ahead of time; otherwise, this seems unwise to broadcast.)
,
Dec 1 2016
Ok; I wasn't aware of that severity evaluation.
,
Dec 1 2016
,
Dec 15 2016
Lukasz, can you answer the question that rdsmith@ is asking?
,
Dec 15 2016
Sorry for the delay. I thought that #c1 makes the answers less important. RE: without the gzip bomb being loaded in the page load preceding the SavePage I think the server can 1) avoid caching via http response headers like Cache-Control and 2) return different data after the page has loaded. I agree that this is a bug that needs to be fixed. I agree with the prioritization and assessment of security impact above.
,
Jan 3 2017
When compressed using Content-Encoding:br, 1.1gb of '0's occupies 2872 bytes, so that's probably the route a bad guy would go. |
||||
►
Sign in to add a comment |
||||
Comment 1 by mmenke@chromium.org
, Dec 1 2016