New issue
Advanced search Search tips

Issue 739090 link

Starred by 7 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Feature



Sign in to add a comment

Downloading windows executable over HTTP in clear-text should provide a red warning

Reported by n...@apps.globaleaks.org, Jul 4 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. Open www.videolan.org website that's in HTTP in clear
2. Click download and follow one of their mirror in HTTP
3. Starts downloading executable

What is the expected behavior?
Chrome should prevent e proovide a big alert windows users that downloading executable files over an insecure channel like HTTP can be subject to man in the middle attacks, regardless of the digital signing of the .exe file (that would be substituted by the attacker).

What went wrong?
Considering the HTTPS deployment strategy of Chrome that now provide warning against mixed HTTPS/HTTP content and warn of providing password over HTTP in clear, it would be a reasonable moves going in the same direction to provide security warning for download of executable codes over insecure HTTP to prevent malware injection attacks.

It's just unreasonable and irresponsible to distribute software executable over HTTP subject to MITM attacks in 2017.

Did this work before? N/A 

Chrome version: 59.0.3071.115  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

The very same should apply for .MSI on Windows and for .DMG and .PKG on Mac OS X.
 
Components: Services>Safebrowsing
Labels: -Type-Bug-Security -Pri-2 Pri-3 Type-Feature
Let me mark it as feature.
Having the same conversation also on Tor Project TorBrowser for Firefox at link https://trac.torproject.org/projects/tor/ticket/22809

The definition of executable could be:
"any installer file that can be directly executed on the target machine"

By having a feature like that in Chrome we will foresee a *huge* increase in software distribution security worldwide and a complete take-down of Infection Appliance provided by Surveillance companies such as HackingTeam and Finfisher (see ​https://twitter.com/botherder/status/882243803448561665 )

Comment 3 by vakh@chromium.org, Jul 28 2017

Labels: OS-Chrome OS-Linux OS-Mac
Owner: elawrence@chromium.org
Status: Assigned (was: Unconfirmed)
elawrence: Is this a duplicate of another bug that you are tracking?

Comment 4 by vakh@chromium.org, Jul 28 2017

Feel free to change the component and remove SafeBrowsing.

Comment 5 by vakh@chromium.org, Jul 28 2017

Labels: SafeBrowsing-Triaged
Going to offer free pasta, mozzarella and italian red wine at SHA2017 Hackers Camp next week for having a chat on that feature request, that i think it's incredibly important in order to change the behaviour of any company serving executable over HTTP.

It would directly impact the efficiency of any governmental MITM applied to inject malware in a simple way, that would only impact the software projects that are really not considering the security of their users, forcing them to upgrade to HTTPS.

Italian food in exchange for security improvement of Chrome :-)
 
Cc: elawrence@chromium.org
Components: -Services>Safebrowsing UI>Browser>Downloads
Labels: -Restrict-View-SecurityTeam Hotlist-HttpBad
Owner: ----
Status: Available (was: Assigned)
Indeed, a primary goal of "Not Secure" warnings is to influence site owners to broaden their use of HTTPS; a non-trivial number of otherwise secure websites are distributing downloads over HTTP via CDNs (e.g. VLC does this).

This is basically a broader version of Issue 509457 and/or Issue 121259.

We have indeed considered some work here under our ongoing HTTPBad project; warning on executables is only part of the task in that there are many different dangerous file types. 

In some respect, Executables are the least interesting of the dangerous types, as there are multiple layers of defense against downloaded executables, including SafeBrowsing and Windows' Attachment Execution Services and SmartScreen, and on Windows and Mac, executables can carry file-based signatures.

Technically, we'd want to warn in three different scenarios:

 1. When the final URL from which the download was served is HTTP or FTP.
 2. When any intermediate URL which redirected to the final URL is HTTP.
 3. When the markup leading to the final download URL was known to be a non-secure context.

Of these, #1 and #2 are straightforward and understandable to the user while #3 is both necessary but confusing to both end-users and many site owners. 
Incidentally, the MoarTLS Chrome extension does offer a "Warn on non-secure downloads" option; screenshots can be found in the announcement: https://textslashplain.com/2016/03/17/seek-and-destroy-non-secure-references-using-the-moartls-analyzer/
It would be also interesting to look for just introducing equivalent warning for the SafeBrowsing when an executable is part of known malware URI.

If it's HTTP-clear-test executable download then it's possibly a malware and the user have no way to know about it.

Also checking that no other resources with "HTTP" are included would be useful.

Governmental malware providers do provided MITM executable infection appliances that wrap executable download with their undetected malware (often also signed on the fly by known CA with authenticode).

That kind of security hole must be closed, actually only Chrome and Firefox together could do that by enforcing full, proper HTTPS security for executable download.
Dear all, consider that Turla Russian APT is exploiting techniques in delivering malware trough sophisticated MITM attacks.

They send legitimate Adobe Flash installer over HTTP, then inject it with malware trough MITM:

https://www.darkreading.com/attacks-breaches/turla-cyberespionage-gang-employs-adobe-flash-installer/d/d-id/1330788

It becomes very relevant to moves on to block downloading of executable over HTTP channel.
Updated also Mozilla Firefox and Tor issue trackers with the problem being exploited:
https://bugzilla.mozilla.org/show_bug.cgi?id=1303739
When software does not provide full HTTPS delivery chain, people can die.

Please let's close this loop-hope by preventing download of executable over HTTP in clear-text.

https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/
Cc: jdeblasio@chromium.org

Sign in to add a comment