New issue
Advanced search Search tips

Issue 670359 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

SaveFileResourceHandler::OnReadCompleted doesn't apply any backpressure to the request

Project Member Reported by rdsmith@chromium.org, Dec 1 2016

Issue description

SaveFileResourceHandler::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.)

 
Should this really be restricted?  Browser OOM attacks are generally considered sec-severity-none exploits, and this one requires a fair bit of effort to trigger.
Labels: -Restrict-View-Google
Ok; I wasn't aware of that severity evaluation.

Labels: -OS-Mac OS-All

Comment 4 by dah...@chromium.org, Dec 15 2016

Cc: -lukasza@chromium.org dtrainor@chromium.org
Labels: -Pri-2 Pri-3
Owner: lukasza@chromium.org
Status: Assigned (was: Untriaged)
Lukasz, can you answer the question that rdsmith@ is asking?
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.
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