Confirmed repro and details above. 

Chrome doesn't make it clear where the downloaded file came from; this effectively is a user-mediated cross-origin-read attack.

Mozilla directly protects against this; discussion is in https://bugzilla.mozilla.org/show_bug.cgi?id=874009 and https://bugzilla.mozilla.org/show_bug.cgi?id=676619.

Edge simply changes the file extension (to e.g. .html), which likely wasn't intended as a mitigation (and it's not very effective).

nparker, are people on your team also interested in download shenanigans? 

This reminds me of http://crbug.com/589747 in that the user really has no insight into where downloads come from or how they were transported.  I think this is outside the scope of Safe Browsing.

mkwst: Any idea who the right owner for this would be?

mkwst: Uh oh! This issue still open and hasn't been updated in the last 15 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Hrm. Probably me, I guess, though I don't know who might know how many developers might be relying on the current behavior.

If Mozilla folks have gotten away with restricting `a@download` to same-origin endpoints, perhaps we could do the same. We'd need to carve out an exception for `data:` and ensure that it worked from within a sandboxed frame, which might be a little complicated, but is certainly doable.

mkwst: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Re #9, blocking cross-origin <a download> would also mitigate against issue 587956 which uses the same mechanism. I think it would be a good idea. Any updates on a plan?

 Issue 651043  has been merged into this issue.

 Issue 651043  notes that we prevent cross-origin callers from specifying the suggested filename using the DOWNLOAD attribute:

  suggestedName = (isSameOrigin ? fastGetAttribute(downloadAttr) : nullAtom);

... but as shown in this repro, if the server fails to specify a Content-Disposition header, our GetSuggestedFilenameImpl function falls back to groveling the URL for something that looks like a filename (e.g. result.pwn is the example used here). 

If the server is willing to serve a file using attacker-controlled text after the "true" path (e.g. the "/LITERALLYANYTHINGHERE" in "https://mtouch.facebook.com/events/upcoming/LITERALLYANYTHINGHERE") then the user (this bug) or their operating system (651043) may take unsafe action.

> Any updates on a plan?

I think the plan is: "This sounds like a good idea. Someone should send an intent-to-make-developers-that-rely-on-this-behavior-sad email to blink-dev@."

Raymes, are you that person? If not, I can probably ask my intern to be that person. Or find someone who's interested in an exciting 20% project.

Looks like Raymes doesn't want to be that person? Mike, should we find anybody else?

Sorry I didn't see this because I wasn't cc'd! I'm not the right person I was just posting as security sheriff previously :(

And another Security Sheriff ping.  mkwst -- do you have said intern, or 20%'er you could rope in?  Thanks

Friendly ping from Security Sheriff. mkwst, any update?

Since Firefox already blocks cross origin <a download> tags, I assume there wouldn't be a strong opposition to an intent to deprecate them. Does anyone volunteer to send that I2D?

Sorry! I support the limitation to same-origin endpoints, but I have no bandwidth to poke at this. Removing myself, marking as available.

OWP launch  issue 714373 

should we outright block downloads, or just mark them as dangerous?

and if we mark them as dangerous, should we mark them as "maybe dangerous content" or introduce a new danger type?

+dahlke@.  I'm personally fine with blocking these.  Do we have any idea with how often this happens or if it's a relatively common site behavior?

I don't know how common that is. Maybe we should for M60 as DOWNLOAD_DANGER_TYPE_DANGEROUS_FILE and add UMA for this, and then decide what to do?

That sounds good to me as well :).

We are looking into requiring a user prompt (similar to pop up blocking and cross-origin navigations) prior to downloading from a cross-origin frame (downloading would be blocked entirely from sandboxed iframes). Would that meet the need here or do we need to be more restrictive?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/99a1d0db25c2b77ad42d216b2289e0bf67c69540

commit 99a1d0db25c2b77ad42d216b2289e0bf67c69540
Author: Jochen Eisinger <jochen@chromium.org>
Date: Fri May 26 14:16:45 2017

cross origin downloads w/o content disposition are dangerous

BUG= 714373 , 608669 
R=dtrainor@chromium.org

Change-Id: I170ad3a3bec4afe64897a16c98c25e8a152c15ed
Reviewed-on: https://chromium-review.googlesource.com/513923
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475000}
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/chrome/browser/download/download_browsertest.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/chrome/browser/download/download_browsertest.h
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/chrome/browser/extensions/api/web_navigation/web_navigation_apitest.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/chrome/browser/loader/chrome_resource_dispatcher_host_delegate_browsertest.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_browsertest.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_create_info.h
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_item_impl.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_item_impl.h
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_item_impl_unittest.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_request_core.cc
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/content/browser/download/download_stats.h
[modify] https://crrev.com/99a1d0db25c2b77ad42d216b2289e0bf67c69540/tools/metrics/histograms/enums.xml

I'd argue that we shouldn't merge this back, but rather have it roll to stable in the regular way, as this might break CDNs that don't correctly send the content disposition header.

that appears to break too much :/

The commit in Comment 41 was reverted on May 30. jochen@ what are the next steps needed for this bug?

Still trying to figure out a way to implement this w/o breaking the web. The reason for the revert was that we ended up blocking about 5% of the downloads which is way more than what was expected.

bumping up (even though I'm not sure we'll get that in M64 either)

Another ping in case anyone got an idea on how to avoid breaking the web.

i have a wip CL to implement Firefox' navigation behavior, however, that won't land before the non-PlzNavigate code is gone.

Calling it Started based on #50. :)

looks like we'll actually make m65

landed as https://chromium.googlesource.com/chromium/src/+/2a6afcb26ba6cd2324ddaa366b11968237e304a3

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Thanks for the report, the VRP panel decided to award $500 for this. By the way, how would you like to be credited in your release notes?

Hi, thank you for the reward. You can credit me as Inti De Ceukelaire, if we can add a URL: intigriti.com

Thanks, we will credit you as: Inti De Ceukelaire (intigriti.com)

This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

[Bulk Edit]

+awhalley@ (Security TPM) for M65 merge review

Already in 65

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