+++ This bug was initially created as a clone of Bug #916126 +++ Steps to reproduce: Download any executable file on Windows, the file properties and find the "Unblock" button. Note that opening file is not a reliable way to determine if the file is marked on Win8+. Actual results: In Firefox 24 or 26 and later, a saved downloaded executable is not treated as an untrusted file by Windows, such that "Unblock" is not present. Expected results: In Firefox 25 or 23 and earlier, the file is stored on the harddisk as coming from the Internet, such that Windows shows a "Unblock" button in the properties dialog. We should really have an automated test to catch the regression...

Correction: Executables files are marked correctly, but non-executable files (e.g. zip files) aren't. Attackers can easily bypass the check by wrapping executables with a zip file.

Regressed by: b6cce1e41253 Monica Chew — Move execution from nsExternalAppHandler to nsDownload (b=858234, r=paolo)

Could you please re-read bug 909022 and tell us why you think this a regression? E.g. on Mac OS and Windows, both platforms supports "zones". Per default, both platforms will mark any files coming from different sources with zone information. But the user can disable that functionality (some may also call this a policy). A decision for Firefox was made (see bug 909022) to ignore the system's policy. Also, because Firefox will now ignore the user's wishes, they decided to only mark executable files. So I don't understand where you see a regression. It reads like a *wanted* change. And if you still see a regression, could you please answer what you want to do when attackers would move to encrypted archives to bypass these checks? Would you like to disable the capability to download encrypted archives or remove the capability to download anything completely because a user could do so much harm to the world and his system with downloaded files? Don't get me wrong. Educate the user, but don't treat the user like someone you want to protect for himself.

(In reply to Igor from comment #3) > Could you please re-read bug 909022 and tell us why you think this a > regression? Because non-executable files were marked at the time of bug 909022 was fixed. Therefore this is an unintentional change, I believe. Alice: it is impossible for bug 858234 to cause a regression since Firefox 26. It must have the second regression range between Firefox 25 and Firefox 26.

(In reply to Masatoshi Kimura [:emk] from comment #4) > Alice: it is impossible for bug 858234 to cause a regression since Firefox > 26. It must have the second regression range between Firefox 25 and Firefox > 26. No. In Firefox25(when that was beta), the offending patch of bug 858234 was backed out by Bug 916126. However, Bug 916126 did not change anything for Aurora26 and Nightly27. So, In Firefox26 +, the problem continues existing.

It looks like removing line 421 (the if file.isExecutable() check) from toolkit/components/jsdownloads/src/DownloadIntegration.jsm in the original patch for bug 909022 may cause the desired behavior

This change is intentional, we don't mark non-executable files as coming from the Internet zone anymore. Previously, we used the system-level policy and marked some (not all) non-executable files as well. In summary, the reason for this change is that using the system-level policy like we did before would cause performance issues and possible hangs when downloads terminate. You may want to read the full details in the mailing list thread <https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000848.html>, as well as bug 909022. When determining which new default policy to apply, we chose to mark only files that we know can be directly executed with a single click from the Downloads Panel. Marking the file causes a warning message to appear before the file can be executed. The purpose is to avoid that potentially dangerous files can be executed accidentally. In most if not all configurations, extracting a program from a ZIP file and executing it requires several steps, including at least an explicit confirmation message box. Thus, an additional warning does not serve the stated purpose, and I believe that in most cases it is unwanted. Moreover, we know that marking all downloaded files as requiring a security warning, regardless of whether they are executable files, text files, or archives, will most probably be an annoyance. This is a trade-off between performance, security, and usability. Unless new developments occur in any of these areas, it is unlikely we'll revert to the previous behavior. Thanks for reporting the issue as a separate bug anyways! This helps in clarifying that the change is intentional, in case other people wonder. Probably it was difficult to track the change in Bugzilla, because the involved code paths have changed between Firefox 25 and Firefox 26, and also a separate regression (unrelated to this choice) occurred in bug number 858234 and was fixed by bug number 916126 (that applies to Firefox 24 ESR and Firefox 25, but not Firefox 24 or 26, see the status flags there).

(In reply to :Paolo Amadini from comment #7) > This change is intentional, we don't mark non-executable files as coming > from the Internet zone anymore. Previously, we used the system-level policy > and marked some (not all) non-executable files as well. What kind of non-executable files were not marked by the system-level policy? I have never seen such an example. > In summary, the reason for this change is that using the system-level policy > like we did before would cause performance issues and possible hangs when > downloads terminate. You may want to read the full details in the mailing > list thread > <https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000848.html>, as > well as bug 909022. The reason of the slowness is because the system check is inseparable from the malware scanning. Writing ZoneId should be pretty fast. > When determining which new default policy to apply, we chose to mark only > files that we know can be directly executed with a single click from the > Downloads Panel. Marking the file causes a warning message to appear before > the file can be executed. > > The purpose is to avoid that potentially dangerous files can be executed > accidentally. In most if not all configurations, extracting a program from a > ZIP file and executing it requires several steps, including at least an > explicit confirmation message box. Thus, an additional warning does not > serve the stated purpose, and I believe that in most cases it is unwanted. On Windows, a zip file can be opened just like a folder. And if the zip file contains only single executable, no warnings will be displayed at all unless the zip file is marked. > Moreover, we know that marking all downloaded files as requiring a security > warning, regardless of whether they are executable files, text files, or > archives, will most probably be an annoyance. Security warnings will not be displayed for non-executable files even if they are marked. Marking a zip file will enable the security warning when opening executables inside the zipfile, rather than the zip file itself. Moreover, if the user download a html file and open it from Internet Explorer, the user will see MORE security warning than the a marked html file because marked html files will be treated as if they came from Internet Zone while unmarked html files will be treated as if they came from Local Computer Zone. > This is a trade-off between performance, security, and usability. Unless new > developments occur in any of these areas, it is unlikely we'll revert to the > previous behavior. I didn't request to revert the previous behavior (i.e. using the system-level policy). I was requesting to remove the check for executable files (file.isExecutable() check).

(In reply to :Paolo Amadini from comment #7) > Moreover, we know that marking all downloaded files as requiring a security > warning, regardless of whether they are executable files, text files, or > archives, will most probably be an annoyance. I have some questions, not being familiar with the specifics of these system APIs: 1) I assume from what you wrote above that Windows shows the warnings on file open indiscriminately if the file is marked, regardless of file type? (If so, this seems sub-optimal. Seems like it is in a better position to determine a file's "riskiness", and so it would be nice to delegate that decision to the system.) 2) What behavior do other browsers (Chrome, IE) have with regard to Internet-zone marking? Do they cause the "annoyance" you're referring to?

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #9) > 1) I assume from what you wrote above that Windows shows the warnings on > file open indiscriminately if the file is marked, regardless of file type? No. Rather, it will *reduce* warnings for some file types (such as hrml files) if the file is marked. > 2) What behavior do other browsers (Chrome, IE) have with regard to > Internet-zone marking? Do they cause the "annoyance" you're referring to? AFAIK, Chrome and IE will mark all files from Internet Zone. But Paolo said "some (not all) files" would be marked. It's the reason I'm asking him for an example of non-marked files.

> (such as hrml files) s/hrml/html/;

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #9) > 2) What behavior do other browsers (Chrome, IE) have with regard to > Internet-zone marking? Do they cause the "annoyance" you're referring to? System: Windows 7 SP1 x64 (Patch level: current, Dec 2013) - Mozilla Firefox 26.0.0 - Google Chrome v32.0.1700.68 beta-m Windows Policy "SaveZoneInformation" is not set (e.g. default). "browser.download.saveZoneInformation" is "true" (default) in Firefox. Test 1: Downloading http://www.example.org/foo.exe ================================================== Firefox: "foo.exe" is marked as coming from the internet (File property window displays "Unlock" button). Chrome: Same as Firefox. Test 2: Downloading http://www.example.org/foo.zip (containing foo.exe) ======================================================================= Firefox: "foo.zip" was not marked. The unpacked "foo.exe" wasn't marked, too. Chrome: "foo.zip" was marked. The unpacked "foo.exe" was marked, too. Notice: If you unpack "foo.zip" using WinRAR, 7z or another program, "foo.exe" won't be marked. Only if you use the built-in Windows ZIP functionality (i.e. use Explorer to open the ZIP file) "foo.exe" will be marked (but only if the archive was marked). If the user set the SaveZoneInformation policy to save the Zone information, Google Chrome will honor the user's decision (Firefox don't). PS: Chrome is using the IAttachmentExecute API (http://support.microsoft.com/kb/883260/en), which will mark if not disabled by the user, trigger the Anti-Virus program etc.)...

Sorry for the delayed response here. After Masatoshi's comment 8, I did some testing on a pristine Windows 7 system and verified that I was mistaken in believing that low risk file types were not marked as coming from the Internet zone. I misread <http://support.microsoft.com/kb/883260> about IAttachmentExecute and probably didn't execute my previous tests correctly. As Masatoshi pointed out, all files are marked, and then the operating system makes a choice about the risk level and whether to show the warning or not at the time of execution. Comment 7 is thus incorrect. (In reply to Masatoshi Kimura [:emk] from comment #8) > I was requesting to remove the check for executable files (file.isExecutable() check). This makes sense - we're not introducing unnecessary warnings by doing this. We should be aware that after changing this we'll need to direct users to the "browser.download.saveZoneInformation" preference in about:config in case the presence of zone information on low and medium risk file types is not desired. We may also consider checking the SaveZoneInformation registry value ourselves instead, given that it turns out it's the only one we need to check, and we don't need to make complex decisions based on the other registry keys mentioned in the article to decide whether to mark the file or not.

Taking. Building on try: https://tbpl.mozilla.org/?tree=Try&rev=30ab238691cb

Comment on attachment 8357271 [details] [diff] [review] Remove our own executable check and pref check, and added a regitry check when downloading a file Green on try.

Comment on attachment 8357271 [details] [diff] [review] Remove our own executable check and pref check, and added a regitry check when downloading a file Thanks for patching this! >diff --git a/toolkit/components/jsdownloads/src/DownloadIntegration.jsm b/toolkit/components/jsdownloads/src/DownloadIntegration.jsm >+ _saveZoneInformation: function() { >+ let key = Cc["@mozilla.org/windows-registry-key;1"]. >+ createInstance(Ci.nsIWindowsRegKey); >+ } finally { >+ if (key) key.close(); Seems like key can never be null here (createInstance would have thrown). (but if you were keeping this, you should put the statement on a separate line from the if()! :)

Are you sure you are doing it the right way? I am not sure but I think you should *not* read this registry key on your own. When looking at the Chomium source code... it seems like they use the IAttachmentExecute interface when available (they have SetInternetZoneIdentifierDirectly for <=WinXP.SP2), which will do all the magic: - The interface will check if it has to mark the file or not - If it has to mark the file, it will mark it... - It will call anti-virus scanners... - Check if there is a policy in place which disallow the downloaded file... Remember, there is more than just marking files as coming from internet. But when using IAttachmentExecute you would support all these functions, including policies.

I'm leaning towards revisiting our decision not to use IAttachmentExecute (https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000848.html). I never fully understood the cause of the issues described in that post, and it seems like perhaps something like bug 448446 could address them.

Comment on attachment 8357271 [details] [diff] [review] Remove our own executable check and pref check, and added a regitry check when downloading a file Review of attachment 8357271 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for taking this bug. The patch looks good, mostly nitpicking to match the style of the surrounding code. ::: toolkit/components/jsdownloads/src/DownloadIntegration.jsm @@ +519,5 @@ > + * Internet Zone. > + * > + * @return true if files should be marked > + */ > + _saveZoneInformation: function() { I'd call this _shouldSaveZoneInformation or something like that, to make it clear that this function does not save the information. @@ +532,5 @@ > + // If the key is not present, files should be marked by default. > + return true; > + } finally { > + if (key) key.close(); > + } Indentation nit: let key = Cc["@mozilla.org/windows-registry-key;1"] .createInstance(Ci.nsIWindowsRegKey); Style nit, please read constants from the interface instead of instances: Ci.nsIWindowsRegKey.ROOT_KEY_CURRENT_USER And finally, better having two separate try blocks: try { key.open(...); try { return key.readIntValue... } finally { key.close(); } } catch (ex) { return true; } Style nit: catch "ex" instead of catch "e".

(In reply to Igor from comment #19) > - It will call anti-virus scanners... We do *not* want to call malware scanner unless the performance/hang issue is resolved. Real-time AV scan will scan the file when opening it anyway.

Fixed style nits.

Flagging in-testsuite? as per the last line of comment 0. Also flagging for verification by QA. Paul, can you have a look at this?

Reproduced in nightly 2014-01-08. Now the properties/unblock button is displayed for .zip, .mar, .doc, .mp3 files. Verified fixed FF 29.0a1(2014-01-14), Win 8.1 x86.

Thanks Paul.

Is there a way to disable the default behavior of marking downloaded files as unsafe (and therefore blocked)? In nightly 29.0a1 (2014-01-25) there is no browser.download.saveZoneInformation pref in about:config (it's been missing for more than a week if I remember correctly) and even if I add manually a pref with that name of boolean type and set it to false, it still doesn't work. In any case, I haven't found a way to download files without alternate data streams, and it's driving me nuts. Thanks in advance.

(In reply to jupiters02 from comment #29) > Is there a way to disable the default behavior of marking downloaded files > as unsafe (and therefore blocked)? > In nightly 29.0a1 (2014-01-25) there is no > browser.download.saveZoneInformation pref in about:config (it's been missing > for more than a week if I remember correctly) and even if I add manually a > pref with that name of boolean type and set it to false, it still doesn't > work. > In any case, I haven't found a way to download files without alternate data > streams, and it's driving me nuts. > Thanks in advance. Disable it from Group Policy or Registry Editor, just like other browsers.

(In reply to Masatoshi Kimura [:emk] from comment #30) > Disable it from Group Policy or Registry Editor, just like other browsers. So there's no browser-wide option to disable the behavior of saving downloaded files without alternate data streams, it has to be system-wide? May I ask the reason why the option to disable this behavior was removed? Besides, it was "hidden away" from the average user in the about:config options.

Why do you want disable the zone id only on Firefox?

sorry to pull back up this thread but as FF 29 has been released we have now encountered this issue. We would like a way to say anything coming from internal.domain.com not get marked or a way to remove it just for FF.

(In reply to hogster from comment #33) > sorry to pull back up this thread but as FF 29 has been released we have now > encountered this issue. We would like a way to say anything coming from > internal.domain.com not get marked or a way to remove it just for FF. Hi hogster, You may have better luck getting this question answered at support.mozilla.org.

(In reply to Masatoshi Kimura [:emk] from comment #32) > Why do you want disable the zone id only on Firefox? Firstly - Finding the Zone.Identifier:$DATA alternate data stream added to my downloads for the first time since starting to use Firefox many years ago, <i>eventually</i> brought me to this page - Is there any blog/other less technical announcement of this change somewhere I didn't find? I agree with all points of users since comment 29. Examples of when having this functionality being chosen on a browser level may be helpful: 1) Relative security level needed for a firefox profile of a user, compared to that of a administrator/power user's profile. 2) Multiple installed-Firefox profiles in use, some of which are... 3) Portable Firefox "profile" which is... .. only intended to download txt files/similarly "safe" files. And, finally: 4) Using different browsers for downloading files of different "safety" levels. If checking prefs.js is not a huge code change/efficiency detriment, not sure why this can't be implemented for the convenience of the many (compared to those that can make this change) that feel this Windows feature provides them no benefit, and actually wastes time. Sidepoint: A "what's new" page getting displayed to every user, with every update (Think I have only seen it on major releases), displaying all changes, would be helpful so that one (in this instance) doesn't download 100's of files with this ADS feature unknowingly set, only to then have to spend time finding ways to remove it!

(In reply to morrison_constable from comment #35) > (In reply to Masatoshi Kimura [:emk] from comment #32) > > Why do you want disable the zone id only on Firefox? > > Firstly - Finding the Zone.Identifier:$DATA alternate data stream added to > my downloads for the first time since starting to use Firefox many years > ago, <i>eventually</i> brought me to this page - Is there any blog/other > less technical announcement of this change somewhere I didn't find? Zone.Identifier:$DATA is the very technical implementation details. Less technical announcement is unlikely to state it. > 1) Relative security level needed for a firefox profile of a user, compared > to that of a administrator/power user's profile. The group policy setting is configurable per-user. > 2) Multiple installed-Firefox profiles in use, some of which are... > 3) Portable Firefox "profile" which is... > > .. only intended to download txt files/similarly "safe" files. And, finally: > > 4) Using different browsers for downloading files of different "safety" > levels. > > If checking prefs.js is not a huge code change/efficiency detriment, not > sure why this can't be implemented for the convenience of the many (compared > to those that can make this change) that feel this Windows feature provides > them no benefit, and actually wastes time. We won't actively support users shooting their foot. > Sidepoint: A "what's new" page getting displayed to every user, with every > update (Think I have only seen it on major releases), displaying all > changes, would be helpful so that one (in this instance) doesn't download > 100's of files with this ADS feature unknowingly set, only to then have to > spend time finding ways to remove it! The "what's new" page has the link to "complete list of changes". But I'm not sure nearly 4000+ changes will really help: https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&f1=target_milestone&o3=equals&v3=Firefox%2029&o1=equals&resolution=FIXED&o2=anyexact&query_format=advanced&f3=target_milestone&f2=cf_status_firefox29&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&v1=mozilla29&v2=fixed%2Cverified&limit=0&list_id=10157763

s/nearly 4000+ changes/nearly 4000 list of changes/;

(In reply to Masatoshi Kimura [:emk] from comment #36) > (In reply to morrison_constable from comment #35) > > (In reply to Masatoshi Kimura [:emk] from comment #32) > > > Why do you want disable the zone id only on Firefox? > > > > Firstly - Finding the Zone.Identifier:$DATA alternate data stream added to > > my downloads for the first time since starting to use Firefox many years > > ago, <i>eventually</i> brought me to this page - Is there any blog/other > > less technical announcement of this change somewhere I didn't find? > > Zone.Identifier:$DATA is the very technical implementation details. Less > technical announcement is unlikely to state it. I used the technical term so that those searching would hopefully find this page. My <i>eventually</i> was due to the number of searches I had to do to find any information about what had changed and why (I guess due to the relative newness of this release). > > 1) Relative security level needed for a firefox profile of a user, compared > > to that of a administrator/power user's profile. > > The group policy setting is configurable per-user. Which necessitates changing registry settings by potentially novice administrators, who aren't using more expensive versions of Windows with GPO functionality exposed in the GUI. Any way to deal with no 2. below? Realise that 3. is technically not Mozilla's responsibility. > > 2) Multiple installed-Firefox profiles in use, some of which are... > > 3) Portable Firefox "profile" which is... > > > > .. only intended to download txt files/similarly "safe" files. And, finally: > > > > 4) Using different browsers for downloading files of different "safety" > > levels. > > > > If checking prefs.js is not a huge code change/efficiency detriment, not > > sure why this can't be implemented for the convenience of the many (compared > > to those that can make this change) that feel this Windows feature provides > > them no benefit, and actually wastes time. > > We won't actively support users shooting their foot. Previous versions allowed users aware of the setting, to turn off download virus scanning. Implementing a way to disable Zone.Identifier setting in prefs.js (set to false, by default) seems just as responsible as the above setting, and if I think/research more, probably other examples. My time in IT support is testament to users not really reading security prompts anyway, so this really only affects those superusers/administrators that care (Probably about efficiency as well as security) - I have other methods that have kept me safe from malware for years, without a warning of dangers I am well aware of/prevention of accidents which haven't happened to me, to date. If this isn't a liability issue (Only reason I can think of why you are happy to differ people to Windows functionality, but not to making an internal prefs.js setting), why the resistance to this change? > > Sidepoint: A "what's new" page getting displayed to every user, with every > > update (Think I have only seen it on major releases), displaying all > > changes, would be helpful so that one (in this instance) doesn't download > > 100's of files with this ADS feature unknowingly set, only to then have to > > spend time finding ways to remove it! > > The "what's new" page has the link to "complete list of changes". But I'm > not sure nearly 4000+ changes will really help: > https://bugzilla.mozilla.org/buglist. > cgi?j_top=OR&f1=target_milestone&o3=equals&v3=Firefox%2029&o1=equals&resoluti > on=FIXED&o2=anyexact&query_format=advanced&f3=target_milestone&f2=cf_status_f > irefox29&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&v1=mozilla > 29&v2=fixed%2Cverified&limit=0&list_id=10157763 Not saying I would even read all the changes, but the longer I didn't discover this subtle change, the more time I would have had to spend correcting it's unwanted effects. Perhaps a warning on the save dialog would have been an idea, at least for a time. I have used and recommended Firefox for many years, partly due to the apparent trust it places in it's users. I worry if this is the start/continuation of a trend. P.S I am not sure how a usability support site like I understand support.mozilla.org is, will be more helpful with a code change, than those on this bugs site.

(In reply to morrison_constable from comment #38) > Which necessitates changing registry settings by potentially novice > administrators, who aren't using more expensive versions of Windows with GPO > functionality exposed in the GUI. Any way to deal with no 2. below? Realise > that 3. is technically not Mozilla's responsibility. I don't think it's more difficult than fiddling with about:config to double-click a .reg file. > Previous versions allowed users aware of the setting, to turn off download > virus scanning. Implementing a way to disable Zone.Identifier setting in > prefs.js (set to false, by default) seems just as responsible as the above > setting, and if I think/research more, probably other examples. Previous about:config settings were provided to avoid the performance issue. Now the problem was fixed. > My time in IT support is testament to users not really reading security > prompts anyway, so this really only affects those superusers/administrators > that care (Probably about efficiency as well as security) - I have other > methods that have kept me safe from malware for years, without a warning of > dangers I am well aware of/prevention of accidents which haven't happened to > me, to date. If this isn't a liability issue (Only reason I can think of why > you are happy to differ people to Windows functionality, but not to making > an internal prefs.js setting), why the resistance to this change? If the security prompt is useless, why do you enable it for other apps/browsers?

(In reply to Masatoshi Kimura [:emk] from comment #39) This (already removed) setting clearly affects most tech-savvy users. They got used to it and shaped their experience over the years. Removing it is not helping a single user on the planet but afects negatively all those users mentioned above. This clearly limits the possibilities for NO reason. Ah, the reason is known - Google and Chrome. I cannot accept any of the reasonings on this thread on removing the pref. "Shooting in the foot", come on. Childish as an excuse. Noone is going to fiddle with this setting in about:config, ever, if s/he doesn't even suspect its presence or meaning. If I want decreased security, I can change the system/IE setting for the same matter, no? => if I can shoot myself in the foot even easier and *affecting the whole system* (as you advice with half open mouth), so why proclaiming such a behavior if I can just shoot my little finger on the foot instead of the whole foot (following your examples)?! This is ridiculous and nonsense. > Previous about:config settings were provided to avoid the performance issue. > Now the problem was fixed. What performance issues? Even if so, now is this removal performance-driven? E.g. leaving the option there and functioning is very resource-intensive?! Because this sounded like a different excuse (other than security's shooting in the foot) to remove the setting. Interesting turn. > If the security prompt is useless, why do you enable it for other > apps/browsers? Because they already mentioned several scenarios when this is undesirable. After all, why removing a feature that was useful to many, and has not been even known to the rest? With every version FF is losing users because of this chrome-fication. If that's the aim indeed..

Please stop doing this. When you fix a bug, there's no need to add extra changes. There was no reason to disable the check of the preference, which was specifically added so peole could choose differently for Firefox than the rest of the system. All you had to do was check the system setting in addition to the Firefox setting. You don't even have the excuse of an increased maintenance burden, since it's the exact same maintenance burden you had before. You have to support the preference being on or off. The idea of removing the pref wasn't even stated in the bug. It wasn't necessary for the behavior to be changed. You did it on a whim. I found this page because I wanted to disable this setting. You now have a much better system in place, one that blocks the file from saving if it is on Google's badware list. The warning is redundant, and just gets in the way. I specifically remember this option being touted when the A/V scan part was removed. It wasn't for performance by that point. If it were, then the option would have been removed altogether. What has happened since then that has changed how you guys handle things?