New issue
Advanced search Search tips

Issue 839986 link

Starred by 3 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 3
Type: Task



Sign in to add a comment

Add insecure download blocking behind flag

Project Member Reported by cthomp@chromium.org, May 4 2018

Issue description

In  Issue 821037  we added UMA metrics to track insecure downloads by content type. While we monitor the metrics, we want to implement the download blocking behind a flag, disabled by default.

This blocking will prevent downloading of unsafe file types (e.g., executables) when either the final download origin or any origin along the redirect chain are insecure (e.g., they are over HTTP).
 
Insecure downloads are particularly egregious because, unlike insecure pages, they can be executed and run outside of the Chrome sandbox.
Project Member

Comment 2 by bugdroid1@chromium.org, May 18 2018

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

commit 2ffffa2c9a8e9c70ceeed46b57f243aadee85970
Author: Christopher Thompson <cthomp@chromium.org>
Date: Fri May 18 23:06:37 2018

Add blocking insecure downloads behind a flag

This adds a feature flag that when enabled blocks downloads of unsafe
types when either the final download origin or any origin in the
redirect chain leading to the download are insecure, and the download
file type is potentially unsafe (that is, of mime-type "application/*").
A console warning is logged when a download is blocked in this way.

This behavior is disabled by default.

Bug: 839986
Change-Id: I9a91c82ea043e4bdec5b33e01dc6611734b57a39
Reviewed-on: https://chromium-review.googlesource.com/1045253
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Min Qin <qinmin@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560089}
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/browser/about_flags.cc
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/browser/download/chrome_download_manager_delegate.cc
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/browser/download/chrome_download_manager_delegate.h
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/browser/download/chrome_download_manager_delegate_unittest.cc
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/common/chrome_features.cc
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/chrome/common/chrome_features.h
[modify] https://crrev.com/2ffffa2c9a8e9c70ceeed46b57f243aadee85970/tools/metrics/histograms/enums.xml

Comment 3 by woxxom@gmail.com, May 19 2018

What about application/json which is the correct MIME type for JSON?
It can't be "potentially unsafe", right?
https://www.ietf.org/rfc/rfc4627.txt
Does this apply to iOS? 
Yes, this would potentially apply to the iOS download manager, but the current flag is not supported on iOS. I'd argue that insecure downloads affect all platforms -- a simple hypothetical would be download an exe on iOS, open in Dropbox/Drive to save it, and then access it on Windows.

We are still measuring downloads in-the-wild and working to come up with a more thorough plan and design doc for how we want to approach this. The flag on desktop at least may allow us to test certain filters in-the-wild to see what breaks (via Finch).
Cc: eugene...@chromium.org
We can try extending Download.IOSDownloadMimeType histogram to measure how often .exe files are actually downloaded on iOS.
That could be a good idea. We're using the Download.Start.ContentType.SecureChain and Download.Start.ContentType.InsecureChain histograms to track download content types on desktop (to separately track when the download chain has any insecure hops and when it is fully secure). I'd be fine looking into adding at least more buckets to Download.IOSDownloadMimeType -- it might not be worthwhile splitting secure/insecure chains since my guess is it is much less common to download EXEs/scripts/etc. on iOS, so the overall numbers may be very small anyway.
iOS Download Manager does not support downloads if the server can not provide a valid SSL cert chain: crbug/com/780911. 


To clarify, when I say "download chain", I'm referring to whether there are any HTTP hops in the redirect chain including the page that initiates the download to the origin that actually sends the download file (rather than an invalid HTTPS certificate anywhere).
Thanks for clarification. web::DownloadTask does not record whether or not a download had http hops in the redirect chain. Adding that should not be hard however.
Project Member

Comment 11 by bugdroid1@chromium.org, Aug 30

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

commit 4fc12293661f93ff1fcf524d208b20fd817623f5
Author: Christopher Thompson <cthomp@chromium.org>
Date: Thu Aug 30 20:24:57 2018

Add connection info to Downloads UKM

This adds the DownloadConnectionSecurity of the download and a boolean
for whether the final download URL is a different host than the
originating URL to the existing Download.Started UKM.

This also refactors out the logic for checking the
DownloadConnectionSecurity into a new public function
(CheckDownloadConnectionSecurity) in download_stats.h and exposes the
underlying DownloadConnectionSecurity enum.

This will help us identify sites that have a lot of downloads over
HTTP (or go over HTTP in their redirect chain) for outreach efforts.

Bug: 839986
Change-Id: I9a1bb78b8c62547e322ec1b85b5acfaa7acc813a
Reviewed-on: https://chromium-review.googlesource.com/1195854
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Robert Kaplow (slow) <rkaplow@chromium.org>
Reviewed-by: Min Qin <qinmin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587737}
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/components/download/internal/common/download_item_impl.cc
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/components/download/internal/common/download_stats.cc
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/components/download/internal/common/download_ukm_helper.cc
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/components/download/internal/common/download_ukm_helper_unittest.cc
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/components/download/public/common/download_stats.h
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/components/download/public/common/download_ukm_helper.h
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/content/browser/download/save_package.cc
[modify] https://crrev.com/4fc12293661f93ff1fcf524d208b20fd817623f5/tools/metrics/ukm/ukm.xml

What if the user has an antivirus? Can Chrome detect it and defer the decision to it?
Antivirus software is a total hit-and-miss and is more often filled with obvious security holes than not. If the download was served insecurely, it could have been modified to contain malware, whether or not that malware is detected by a shoddy antivirus.

Sign in to add a comment