|Issue 591343||Downloads are marked as "could be dangerous" even when downloaded in intranet zone|
|Starred by 1 user||Reported by avonw...@gmail.com, Mar 2 2016||Back to list|
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Add a site which hosts "potentially dangeroud" files to intranet zone 2. Download such a file What is the expected behavior? The file should be saved without security warning. What went wrong? In our specific case, the files come from a local development build server in our intranet. They are ZIP, DLL or EXE files built from our source code, and obviously they are not "commonly downloaded" at that stage. The URL of the build server is in the Intranet zone. Despite this, the download is flagged as potentially dangerous, and the user has to choose to keep it every time he downloads such a resource. Did this work before? Yes Warnings started popping up with recent versions of Chrome, but exact version is unfortunately unknown Chrome version: 48.0.2564.116 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 20.0 r0 An ADM/ADMX policy setting which controls whether to enable Safe Browsing for intranet and/or trusted sites would be helpful, as it could be used to control the behavior depending on the organization needs.
Mar 2 2016,
Mar 9 2016,
Apr 22 2016,
asanka@ -- do you know if it's possible for Chrome to tell if a certain website is in the Intranet zone?
Apr 22 2016,
Apr 25 2016,
+nparker Yeah. Chrome can tell whether a URL is in the intranet zone (Win7's lookup logic isn't quite accurate depending on the zone settings, but Win8+'s logic fixes the issue). We should be able to optionally whitelist intranet downloads if the machine is managed and if some managed policy allows it. If we are doing this, I'm not sure whether to roll this into the whitelist lookup logic or the download protection logic. nparker: WDYT?
Apr 25 2016,
I think it should go in the download protection code, and we should only skip the "uncommon download" warning. Anything classified as malware/uws should still warn even if its from the intranet zone.
Apr 25 2016,
I believe the following managed policy might be a fairly good fit: "Show security warning for potentially unsafe files" (Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Intranet Zone) "This policy setting controls whether or not the "Open File - Security Warning" message appears when the user tries to open executable files or other potentially unsafe files (from an intranet file share by using File Explorer, for example)." Note that I'm aware that this setting affects the File Explorer warnings based on zone information stored alongside the file, but after thinking about it, it feeld consistent to me to disable the warning message in Chrome when I choose to allow unprompted file execution from this zone. This is distinct from the malware screening policies (e.g. SmartScreen policy settings), so I agree with the suggestion to still warn about malware/uws. It may be a good idea to handle this setting for all zones, not only Intranet, so that admins can choose suitable settings (such as disabling the warning for Trusted Sites, or disabling for Internet, etc.). Also, the "Allow file downloads" and maybe "Allow font downloads" managed policy settings could maybe also be taken into consideration since they seem related (I haven't checked if they are currently being respected by Chrome so they might or might not have an effect in current versions).
May 6 2016,
Eric -- Do know how to ask the OS for its view on what zone a particular download URL is in? Are you interested in tackling this? I'd be glad for your expertise.
May 7 2016,
#5 pretty much covers it. In Windows, the URLMON MapURLToZone() function is the canonical source of Security Zone information; this function is used throughout Internet Explorer and essentially everywhere else in Windows, including the Attachment Execution Services APIs (IAttachmentExecute::*) that Chrome presently uses for tagging files with the "Mark-of-the-Web". Firefox calls this API directly when deciding whether to tag a file with the MOTW. Having said that, I do have a few concerns here. Most importantly, it's not clear to me whether bringing more of Windows Security Zones into Chrome is a good idea. Zones are a source of security vulnerabilities (since any misclassification enables bypassing of security checks) as well as considerable complexity; for instance, see https://blogs.msdn.microsoft.com/ieinternals/2012/06/05/the-intranet-zone/ for the nitty-gritty details of how membership in the Intranet zone is computed. Over time, the IE team worked to bring the behavior of both the Intranet and Trusted Sites zones closer to that of the Internet Zone for attack surface reduction purposes. Notably, Chrome does directly consult URLMon Zone settings in some codepaths, including where it decides whether or not to automatically present NTLM/Negotiate credentials (https://code.google.com/p/chromium/codesearch#chromium/src/net/http/url_security_manager_win.cc&q=CanUseDefaultCredentials&sq=package:chromium&type=cs&l=35) Recently, while investigating whether Chrome should dump IAttachmentExecute in favor of a Direct MapURLToZone call, we found that MapURLToZone (on Win7 at least) has a few bugs. First is that its FindProxyForURL()-returned-DIRECT-means-Intranet behavior only works correctly if the WinINET AutoProxy DLL has been initialized in the current process (On Win8+, this should always work because AutoProxy was moved to an always-running system service). Secondly, the group policy that controls whether DIRECT-means-Intranet doesn't appear to be respected in all processes, meaning that even today Chrome is currently failing to accurately MOTW some downloads (because it thinks that the proxy wants them tagged Intranet).
May 12 2016,
Given the extremely poor security history of Zones, I'm going to WontFix this. I just consider it fundamentally unsafe to support anything beyond the simple mark-of-the-web usage that we currently have. If there's some compelling enterprise demand, then we could reconsider implementing this behind an enterprise policy setting.
|► Sign in to add a comment|