959187 - Downloads are no longer scanned with IAttachmentExecute in v26 or higher

Status: NEW

(Toolkit :: Downloads API, defect)

Description

[Alex Cherney]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140109165205

Steps to reproduce:

Download a virus test file (eicar) with on-access scanning disabled and on-demand scanner available.


Actual results:

Downloaded files are not scanned in v26 or v27. The files are scanned using IAttachmentExecute in v25 or earlier.


Expected results:

The downloaded files should be scanned in nsDownloadScanner.cpp

Comment 1

[Alex Cherney]

MS Windows Only

Comment 2

[Jim Mathies [:jimm]]

Last I heard we were planning on getting rid of download scanning and simply relying on 3rd party security apps for this type of security.

https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000848.html

Comment 3

[Alex Cherney]

Thanks for prompt response. Abandoning IOfficeAntivirus (IAttachmentExecute) in Firefox would be a shame. 

We are developing an updated version of open source on-demand virus scanner (Clamwin) and it uses IOfficeantivirus to integrate with browser's download managers. Internet Explorer and Chrome support the interface and Firefox did too until v26 update.

Comment 4

[Daniel Veditz [:dveditz]]

This was an intentional change so no need to keep hidden. It could be WONTFIX for that reason, but I'm not sure we've documented why we no longer need it if our security-savvy competitors (including the inventor of the interface) still think it's necessary.

Comment 5

[Masatoshi Kimura [:emk]]

(In reply to Jim Mathies [:jimm] from comment #2)
> Last I heard we were planning on getting rid of download scanning and simply
> relying on 3rd party security apps for this type of security.

IAttachmentExecute will require 3rd party security apps to scan files anyway.

Comment 6

[Masatoshi Kimura [:emk]]

By the way, are competitors suffered from never-ending scanning? If not, why?

Comment 7

[Alex Cherney]

(In reply to Daniel Veditz [:dveditz] from comment #4)
> This was an intentional change so no need to keep hidden. It could be
> WONTFIX for that reason, but I'm not sure we've documented why we no longer
> need it if our security-savvy competitors (including the inventor of the
> interface) still think it's necessary.

That is rather unfortunate because in our experience there is a significant number of users who do not have on-access scanning enabled (mainly for performance reasons on older PCs) and rely on browser scanning the downloads. In any case it would be preferable if this change was appropriately announced so that the users relying on the on-demand scanning do not find out by accident.

The following settings need to be removed as well as they imply that the scanning is still there:
* browser.download.manager.scanWhenDone
* services.sync.prefs.sync.browser.download.manager.scanWhenDone

Is there any hope that the development team will reconsider and reinstate the IAttachmentExecute scanning, which is supported widely in Windows by IE, Chrome, MS Office and Windows Explorer?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

See bug 952961 comment 20 - I think we should try to revisit this. An answer to comment 6 would also be interesting!

Comment 9

[Marco Bonardo [:mak]]

(In reply to Alex Cherney from comment #7) 
> That is rather unfortunate because in our experience there is a significant
> number of users who do not have on-access scanning enabled (mainly for
> performance reasons on older PCs) and rely on browser scanning the
> downloads.

I honestly think here there is also a technical evangelism issue here, anyone suggesting people to disable real-time protection to rely on some voodoo hidden in apps is just doing it wrong. AV software is today in a much better shape than it was years ago, without taking into account the advancement in hardware power.  The case of users having to disable real-time protection for performance issues is quite an edge case today, and any AV software show very scary warnings when a user disables real-time, so it's not they are uninformed to be unprotected.
On the opposite side, restoring on-demand check, we end up causing double the performance hit on most users (our scan + real-time scan), so if we should look at how to benefit most users, we should consider there's very few reasons to disable real-time and you get warned about risks when doing that. This cost will exist even if, with lots of dev effort, we are able to solve the neverending scans issue.

(PS: I suspect being multiprocess somehow helps with the slow scanning cases)