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
Last visit > 30 days ago
Closed: Dec 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 127522: Security: Chrome Allows "Carpet Bomb" from File Download

Reported by, May 10 2012

Issue description

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.

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

POC:  (unpublished at time of report)

		var dl_link = document.createElement('a');

		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);
1.8 KB View Download

Comment 1 by, May 10 2012

Labels: -Pri-0 -Area-Undefined Pri-2 Area-Internals Feature-Downloads SecImpacts-Stable SecImpacts-Beta SecSeverity-Low OS-All Mstone-19
Status: Assigned
We should reprompt after 50 downloads, but looks like we don't. this problem came up earlier in

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

Comment 2 by, 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?

Comment 3 by, May 10 2012

@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.

Comment 4 by, May 12 2012

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.

Comment 5 by, May 15 2012

Project Member
The following revision refers to this bug:

r137137 | | Tue May 15 08:27:06 PDT 2012

Changed paths:

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
TEST=Retry example in referenced issue; look for throttling message.

Review URL:

Comment 6 by, May 15 2012

Status: Fixed

Comment 7 by, May 18 2012

 Issue 91998  has been merged into this issue.

Comment 8 by, May 18 2012

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, May 18 2012

Labels: -Merge-Requested Merge-Rejected

Comment 10 by, May 19 2012

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.

Comment 11 by, May 19 2012

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, 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.

Comment 13 by, May 31 2012

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, 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.

Comment 15 by, Jun 7 2012

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)

Comment 16 by, Jun 7 2012

@matt: what credit line should I use in the Chrome 21 release notes?

Comment 17 by, Jun 7 2012

"Matt Austin of Aspect Security" would be great.

Comment 18 by, Jul 31 2012

Labels: CVE-2012-2847

Comment 19 by, Oct 13 2012

Project Member
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.

Comment 20 by, Dec 20 2012

Status: Fixed

Comment 21 by, Mar 10 2013

Project Member
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

Comment 22 by, Mar 13 2013

Project Member
Labels: Restrict-View-EditIssue

Comment 23 by, Mar 14 2013

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

Comment 24 by, Mar 21 2013

Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue

Comment 25 by, Mar 21 2013

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

Comment 26 by, Mar 21 2013

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

Comment 27 by, Mar 21 2013

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

Comment 28 by, Jun 14 2016

Project Member
Labels: -security_impact-beta

Comment 29 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot

Comment 30 by, Oct 2 2016

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

For more details visit - Your friendly Sheriffbot

Comment 31 by, Oct 2 2016

Labels: allpublic

Comment 32 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment