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

Issue 608669 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 1
Type: Bug-Security



Sign in to add a comment

Security: a@download feature can be abused to leak sensitive information from third party sites

Reported by inti.de....@gmail.com, May 3 2016

Issue description

VULNERABILITY DETAILS

The a@download attribute can be abused to make someone download sensitive content (csrf tokens, personal info) from a third party website that would appear to come from a server that serves as a proxy. 

There is some user interaction involved, but nothing unrealistic: victim would have to download a file (with name and extension of choice) from a server and re-upload it somewhere else. 

This happens in quite some real-life situations, for example in a PGP key generator like this one (https://pgpkeygen.com/): the user downloads a file and distributes it with its peers.


The issue occurs when a webpage does not throw a 404 error upon loading a non-existing resource on a page that includes sensitive information and CSRF tokens, e.g. 

https://mtouch.facebook.com/events/upcoming/result.pwn

The page will download as result.pwn. We can hide the source by using a server-side redirect on the attackers server,.

We can also exploit the credibility of the source, e.g. when a JSON response at trustedsite.com/response.json/clickme.bat includes ||{malicious batch code}}|| - so an attacker could make the victim download and execute malicious code from a trusted site. This last issue is perhaps lower risk, but a fix would also get rid of this.

I reported this to facebook initially and they suggested contacting you.

Even though this can be prevented by websites individually, the solution isn't always feasible. Tackling this issue on a higher level would be a better solution.


IMPACT

A successful exploitation can be quite disastrous: Google maps leaks personal data such as e-mail, phone number and GPS location, Facebook leaks messages and CSRF tokens, ...

The user interaction is a mitigating factor, but is not too unrealistic. All the victim has to do is to download a file from a server and upload it to (another) server.
 
VERSION
Chrome Version: 50.0.2661.94 m stable
Operating System: Windows

REPRODUCTION CASE

I set up a PoC that'd download your Facebook data and CSRF tokens. PoC is very simple but shows a test that'd download your results as a .pwn file. You can then view the .pwn file in an online viewer, but in reality the contents of the file would be transferred to the attacker's server. This is of course just one simple scenario, there are more possibilities.

1) Download your file here (this can be done automatically)
http://ceukelai.re/d-ownload/index.php?url=aHR0cHM6Ly9tdG91Y2guZmFjZWJvb2suY29tL2V2ZW50cy91cGNvbWluZy9yZXN1bHQucHdu

On this page, you'll find the following piece of code:

<a href="./getresult.php?url=aHR0cHM6Ly9tdG91Y2guZmFjZWJvb2suY29tL2V2ZW50cy91cGNvbWluZy9yZXN1bHQucHdu" download="">here</a>

Which is actually

<a href="https://mtouch.facebook.com/events/upcoming/result.pwn">here</a>


2) As you can see, no references are made to facebook. The victim has no clue that in reality the contents of another website are downloaded as a filename and extension of the attackers choice - whatever suits the scenario.


FIX

Firefox refused to a@download content from third parties, IE/Edge looks at the content type. Also, I think it'd be a good idea to prevent a@downloads from following redirects.
 
Components: UI>Browser>Downloads
Status: Untriaged (was: Unconfirmed)
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).
Labels: Security_Severity-Medium Security_Impact-Stable M-50
Status: Available (was: Untriaged)

Comment 4 by f...@chromium.org, May 10 2016

Cc: nparker@chromium.org
nparker, are people on your team also interested in download shenanigans? 
Cc: palmer@chromium.org
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.
Project Member

Comment 6 by sheriffbot@chromium.org, May 11 2016

Labels: Pri-1
Owner: mkwst@chromium.org
Status: Assigned (was: Available)
mkwst: Any idea who the right owner for this would be?
Project Member

Comment 8 by sheriffbot@chromium.org, May 18 2016

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

Comment 9 by mkwst@chromium.org, May 18 2016

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.
Cc: mmoroz@chromium.org
Project Member

Comment 11 by sheriffbot@chromium.org, May 26 2016

Labels: -M-50 M-51
Project Member

Comment 12 by sheriffbot@chromium.org, Jun 1 2016

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

Comment 13 by ta...@google.com, Jul 13 2016

Labels: OS-Windows

Comment 14 by ta...@google.com, Jul 13 2016

Labels: -OS-Windows OS-All
Cc: -palmer@chromium.org
Project Member

Comment 16 by sheriffbot@chromium.org, Jul 21 2016

Labels: -M-51 M-52
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?
Project Member

Comment 18 by sheriffbot@chromium.org, Sep 1 2016

Labels: -M-52 M-53

Comment 19 by kenrb@chromium.org, Sep 28 2016

Cc: kenrb@chromium.org
 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.

Comment 21 by mkwst@chromium.org, Sep 29 2016

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

Comment 23 by sheriffbot@chromium.org, Oct 13 2016

Labels: -M-53 M-54
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 :(
Project Member

Comment 25 by sheriffbot@chromium.org, Dec 2 2016

Labels: -M-54 M-55

Comment 26 Deleted

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

Comment 28 by sheriffbot@chromium.org, Jan 26 2017

Labels: -M-55 M-56
Project Member

Comment 29 by sheriffbot@chromium.org, Mar 10 2017

Labels: -M-56 M-57
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?

Comment 32 by mkwst@chromium.org, Apr 20 2017

Cc: mkwst@chromium.org
Owner: ----
Status: Available (was: Assigned)
Sorry! I support the limitation to same-origin endpoints, but I have no bandwidth to poke at this. Removing myself, marking as available.
Project Member

Comment 33 by sheriffbot@chromium.org, Apr 20 2017

Labels: -M-57 M-58
Owner: jochen@chromium.org
Status: Assigned (was: Available)
OWP launch  issue 714373 
Cc: dtrainor@chromium.org
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?
Cc: dah...@chromium.org
+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?
Project Member

Comment 41 by bugdroid1@chromium.org, May 26 2017

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

Labels: -M-58 M-61
Status: Fixed (was: Assigned)
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.
Project Member

Comment 43 by sheriffbot@chromium.org, May 27 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: Assigned (was: Fixed)
that appears to break too much :/
Labels: -M-61 M-62
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.
Labels: -M-62 M-64
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.
Labels: -OS-All OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows
Status: Started (was: Assigned)
Calling it Started based on #50. :)
Labels: -M-64 M-65
looks like we'll actually make m65
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-500
*** 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.
*********************************
Cc: awhalley@chromium.org
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?
Labels: -reward-unpaid reward-inprocess
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)
Project Member

Comment 60 by sheriffbot@chromium.org, Feb 8 2018

Labels: Merge-Request-65
Project Member

Comment 61 by sheriffbot@chromium.org, Feb 9 2018

Labels: -Merge-Request-65 Merge-Review-65 Hotlist-Merge-Review
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
Labels: -Merge-Review-65
Already in 65
Labels: Release-0-M65
Labels: CVE-2018-6075
Project Member

Comment 66 by sheriffbot@chromium.org, Apr 23 2018

Labels: -Restrict-View-SecurityNotify allpublic
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: CVE_description-missing
Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment