New issue
Advanced search Search tips

Issue 601187 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

issue 153212
issue 611058

Sign in to add a comment

Stop using AttachmentServices

Project Member Reported by, Apr 6 2016

Issue description

On Windows, once Chrome completes a download, it hands over the download to  Windows AttachmentServices via the IAttachmentExecute interface. This is the recommended practice for saving something obtained from the internet to the local file system. The IAttachmentExecute::Save() method is documented to "run virus scanners or other trust services to validate the file before saving it. Note that these services can delete or alter the file." In addition, it "may attach evidence to the local path in its NTFS alternate data stream (ADS)." (

The evidence in question is the Windows MOTW which indicates the IE security zone of the source of the download. Typically a MOTW indicating that the file is from the Internet or Untrusted zones would cause a prompt to be displayed to the user asking for confirmation before an executable is executed.

In practice, use of AttachmentServices has the following problems:

* It instantiates any and all registered components supporting the MSOfficeAntiVirus category, queries the IOfficeAntivirus interface for each components, and invokes IOfficeAntivirus::Scan() on the component ( If anything goes wrong, or if the scan returns a positive result, AttachmentServices will delete the download file.

  There are lots of things that can go wrong with this process particularly in light of botched upgrades, DLL hell, poorly written AV components, and malware. Since any error condition results in a deleted file, if the user's system enters a misconfigured state, Chrome can no longer download anything on that machine. This is unfortunate because fixing said misconfiguration often involves downloading something.

  Issue 153212 is a particularly bad example of this. The investigation with Microsoft documented in go/case-of-the-missing-downloads has a number of examples of how AttachmentServices can end up in this broken state (Google only link).

  The Download.InterruptReason["FILE_SECURITY_CHECK_FAILED"] UMA bucket counts the number of instances of this. Of all downloads that fail on Windows Stable, around 1.2% fail due to AttachmentServices breaking for some reason. Compare to Download.InterruptReason["FILE_VIRUS_INFECTED"] which is at 2% of all failed downloads. The latter is the bucket that counts the number of instances where AttachmentServices actually catches something.

* It's unreliable. See  issue 598812  for discussion.

Instead of invoking AttachmentServices, we can apply the MOTW ourselves. Doing so involves the following:

  * MOTW will be applied deterministically.

  * 1.2% of downloads that fail due to AS breakage will no longer fail. Note that AttachmentServices is invoked at the end of the download after the final rename. In the absence of AS the only remaining step is writing the MOTW to the alternate data stream. The latter has a substantially smaller failure rate than AttachmentServices.

  * A bunch of code could be deleted.


  * Downloads that are blocked using IE Security Zone policies may stop being blocked. Currently that's 0.3% of all failed downloads. Perhaps this isn't a con.

Interesting points:

  * Most AV products don't rely on IOfficeAntivirus to scan incoming downloads. Instead they rely on on-access scanning. In our previous investigations, the only product that had a tight integration with IOfficeAntivirus was Windows Defender. We should verify that Windows Defender won't lose coverage if Chrome stops using AttachmentServices.

I think there's significant merit in decoupling Chrome's MotW application from the IE/Windows zone settings; as I noted here ( there's a non-trivial risk that the user has unexpected sites in their Trusted Zone (native code installers modify that list from time-to-time) and there's also apparently a bug in the AttachmentServices::Save() function such that it will omit the MotW from any file if the user has a proxy configuration script and that script returns DIRECT for the target site; ( has some background, but the gist of it is that the assignment to the INTRANET zone is supposed to be subjected to the Tools > Internet Options > Security > Intranet > Sites > "Include all sites that bypass the proxy server" checkbox, but it does not appear to be in the event that this box is controlled by policy).

Current versions of Firefox appear to write the Zone.Identifier directly, and do not use IAttachmentExecute:Save(). Interestingly, they do first call out to URLMon to use IE's security settings to MapURLToZone and omit the stream unless the target is in the Internet or Restricted Sites zones.

RE: IOfficeAntivirus -- One non-obvious capability provided by IOfficeAntivirus when called in the context of a download is that it supplies the calling AV package the browser-reported download URL. If that AV scanner decides that the downloaded file contains malicious content, it may report the URL back to the AV company for investigation or blocking via URL reputation etc. I do know not which, if any, AV products take advantage of this capability.
FireFox's behavior is a bit nuanced. The preference is supposed to control whether AttachmentServices is used or not. ( It appears to default to true if not defined. Formerly if is true, then AttachmentServices would be skipped, but that appears to be no longer the case.

I think we may need to carefully consider how we factor in the zone mappings. Enterprises are likely to depend on them for ensuring that internal apps (likely unsigned) aren't blocked or result in warnings to the users. Perhaps have an enterprise policy for controlling whether zone settings would be applied. We won't be able to automatically add sites to the intranet zone based on PAC results.

Thanks for bringing up the URL reporting aspect of IOfficeAntivirus. I wasn't aware of that. Not sure how to factor that in though. Does the benefit outweigh the pain we are trying to relieve? Would it still be an issue if we integrate with AMSI instead?
Blocking: 153212
Firefox's scanWhenDone preference is gone as of Firefox 31, per the reference you cite. Additionally, I also wrote an IOfficeAntivirus provider and confirmed that it wasn't called on downloads in Firefox 48.

> We won't be able to automatically add sites to the intranet zone based on PAC results.

Well, we *could*, by doing the same thing that Firefox does, which is to call URLMon's MapURLToZone function. But doing that would bring back some of the performance and reliability problems we'd otherwise be mitigating by moving off IAttachmentExecute.

I don't know how to factor in the loss of the URL-reporting feature either; I'm not convinced it's very important (does Chrome itself use "HadAVirus" as a telemetry signal to the Safe Browsing webservice?). The new AmsiScanBuffer function ( does expose the original URL to an AV-engine that implements that interface but so far I'd be cautious not to assign that much weight, as it's not clear how many AV engines will implement the new interface, and it's Win10 only.
Not sure what changed at FireFox. The edit you mention (that is't no gone as of FF 31) isn't corroborated with any bug or code change and seems to be based on a forum post. Also nsDownloadManager.cpp still supports the pref. So I can't dig into why the behavior change happened if it did.

Also, URLMon's MapURLToZone doesn't take PAC results into consideration.
I'm inclined to dump IAttachmentExecute in conjunction with the plans to support AMSI as an explicit user opt-in, along with aggressive third-party code blocking.

Comment 7 by, Apr 7 2016

MS has said that IOfficeAntivirus is still to be used for file downloads. It's not clear that they expect AMSI to replace it (at least not soon).
> isn't corroborated with any bug

> URLMon's MapURLToZone doesn't take PAC results into consideration.

Why do you believe that? (I owned this API from 2004-2012, and I've reconfirmed that a PAC result of DIRECT results in Zone=1 just now)

> > isn't corroborated with any bug

The edit to the Wiki page was based on a forum post by someone complaining that the pref doesn't work with no information about why or exactly what the new behavior is.

But it looks like is where the functional change was made. It appears the motive was to resolve performance / hang issues and the justification was that on-access scanning should suffice. The current code is

It certainly agrees with your observation that MapURLToZone is being called but IAttachmentExecute is not.

(As an aside and might save some time in tracking down what's going on, in the future).

> > URLMon's MapURLToZone doesn't take PAC results into consideration.
> Why do you believe that? (I owned this API from 2004-2012, and I've reconfirmed that a PAC result of DIRECT results in Zone=1 just now)

You also need to verify that the same host would map to the Internet zone if the PAC result was different :-)

The reason I believe it doesn't work is due to things like issue 121519. We currently use MapURLToZone in HTTP authentication code (look for URLSecurityManagerWin::CanUseDefaultCredentials). We've had numerous reports over time that their proxy results aren't factored into the authentication decision, which we narrowed down to MapURLToZone not considering their proxy result.

So, does MapURLToZone go through the process of fetch the PAC script and evaluating it to determine the zone? (Perhaps we can take this conversation elsewhere since it's not contributing to this issue. But I'd certainly like to pick your brains on URLMon.)

#6, #7: Thanks. I suppose that means AMSI can't realistically be considered an alternative at this time. :-/ However, I think moving away from AttachmentServices is still an option if we can determine that on-access scanning is sufficient.

Blocking: 611058
Unfortunately, we may not be able to remove this. We've decided we're going to follow suit with Edge and not support AMSI. So, this is the only direct integration path we have for download scanning. Could we maybe get better data on what AV/AM is installed when we have problems, and maybe try a more targeted approach to solving this?
If we decided that support for IOfficeAntivirus is important to maintain, we could simply invoke registered scanners in that COM component category directly.
So, we'd manually set the mark of the web, and invoke the scanner directly rather than using it for save? If so, I'm good with that approach.
SGTM to me as well.

elawrence: Should we still perform the zone lookup based on the download URL? Marking downloads as being from the internet zone might cause problems for enterprises that rely on some downloads being mapped to intranet / trusted zones.

Zones are a nightmare -- so much so that Microsoft dropped support for them in Edge. So, we should just follow suit here and treat everything as untrusted.
There's a similar question, about whether we should have "special" behavior for Smart Browsing evaluation of downloads in "the Intranet Zone":

Generally, my concern is that Windows' Zones are a horrible mess, and the more we plumb them into Chrome, the more complexity we undertake and the greater we are at risk of encountering bypasses and unexpected behaviors (e.g. for people who never touch IE and never expect Chrome to respect settings controlled and configured by IE UI and policies). Respect for Security Zones is a larger-scope architecture decision that the Chrome team should probably think about holistically. 

For this specific issue, NOT calling MapURLToZone() in our new code would mean that the user-experience will change vs. what we have today, and in my experience users and enterprises tend to have severe allergies to change. So we probably do at least need to offer an Enterprise Policy to allow things to work the way they used to, especially on, say Windows 8+ where Explorer's SmartScreen integration will block execution of "unknown" binaries from the Internet Zone.

As we start to consider replicating essentially all of the functionality in IAttachmentExecute, I wonder if this investment will yield much benefit-- we might get slightly better data about where in the process a given file is blocked, but we're still opening ourselves up to all of the flakiness of IOfficeAntivirus providers, URLMon Zone Mapping, etc, etc.
Re #15: I'm not convinced that Edge really dropped Zones; I think they just reduced the number of places that ProcessURLAction is consulted.

As far as I can tell, features like automatic credential release and file download tagging, Edge is still using Zones. 
Well, I'm sad Edge didn't completely drop support, but I still consider them too error-prone and dangerous to support in Chrome.
Blocking: -598812

Comment 20 by, Sep 11 2016

Labels: -Restrict-View-SecurityNotify
Status: WontFix (was: Untriaged)
So it seems the consensus is that we can't stop using AttachmentServices yet. To summarise:

* We can't stop respecting Windows policy around AttachmentServices. See  issue 650111  for example where we accidentally started manually stamping MOTW on all downloads for a few Canaries.

* We can't stop respecting the Intranet Zone. It's something enterprises rely on.

* We don't want to entangle Chrome's downloads logic with UrlMon any more than absolutely necessary. By implication we don't want to manually probe the zone and download opening policy from Chrome.

Thanks everyone for the discussion. We may revisit this again some time in the future, but at least for the moment I'm going to try to resolve the blocked issues on the assumption that AttachmentServices is not going away.


Sign in to add a comment