Open Bug 1619583 Opened 4 years ago Updated 4 years ago

Malicious .exe content is saved as .html and download warning is not displayed

Categories

(Toolkit :: Safe Browsing, defect, P3)

Desktop
Windows 10
defect

Tracking

()

ASSIGNED
Tracking Status
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- affected
firefox76 --- affected

People

(Reporter: vlucaci, Assigned: dimi)

Details

Attachments

(1 file)

Affected versions

  • 75.0a1(ID:20200302212732)
  • 74.0(ID:20200302184608)
  • 73.0.1(ID:20200217142647)
  • 71.0(ID:20191202093317)

Affected platforms

  • Windows 10 x64
  • Windows 7x64
  • Windows 10x64 ARM

Steps to reproduce

  1. Launch Firefox and navigate to http://testsafebrowsing.appspot.com/
  2. Go to Desktop Download Warnings
  3. Right click the "link" in order to trigger the context menu.
  4. Select "Save link as" option and save it locally.

Expected result

  • Once the download is finished, a "malicious" warning is displayed.

Actual result

  • Once the download is finished, a "malicious" warning is never displayed.

Regression range

  • Will return with a regression ASAP
Component: Messaging System → Safe Browsing
Product: Firefox → Toolkit

Hi Vlad,
I can't reproduce this issue on my mac, does this only happen in Windows?
Could you help set MOZ_LOG="ApplicationReputation:5" and dump the log? thanks!

Helo Dimi,

Yes, this is a Windows specific issue. macOS and Ubuntu is not affected.

Log attachment: https://drive.google.com/open?id=1z5bsc9pWjOviz5ZqNGRFMEvo6sWmXjPN
Hope this helps.

Priority: -- → P1
Assignee: nobody → dlee
Status: NEW → ASSIGNED

Hello,

I have returned with results in regards to the regression range.

I went as far back as 2016-03-05 and got the following pushlog(but without finding any Good Try Build):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33d36bf6ca0c9d9c22cadf6d8223fa6e1418b62c&tochange=5a2e0878d6c258b36b0ee8712a2afcde6ad94c78

A few notes:

  • The first two (affected) links from Desktop Download Warnings used to have the expected behavior when selecting "Save Link as" last year when QA used this in our tests.
  • Chrome 80 has the expected behavior of downloading this as .exe format and displaying a malicious warning.

Until we clarify this, I will leave the regression-wanted keyword.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Has Regression Range: --- → yes

hi gijs,
In the download links of SafeBrowsing testing page, the content type it returns now becomes "text/html"(maybe since a couple of month ago, see Bug 1613149).

If we save those files via "save link as" in Windows, it is saved as an html file. But in macOS or Linux, it is still saved as "exe".
This makes the information carried within the download protection ping differ in Windows and other platforms, which affect the result of download protection ping(but I haven't checked which part of the information affect the result).

just want to check with you first to know if this is intentional, thanks!

Flags: needinfo?(gijskruitbosch+bugs)

When we right click the file and choose "save link as", we make a request to determine the mimetype, and end up in https://searchfox.org/mozilla-central/rev/c79c0d65a183d9d38676855f455a5c6a7f7dadd3/browser/base/content/nsContextMenu.js#1429 . This passes the mimetype (which is text/html).

::DoContent then calls CreateListener, which calls GetFromTypeAndExtension, having deduced the .exe file extension from the URL.

So we end up in platform-specific GetMIMEInfoFromOS, called from the above.

On Windows, that starts by asking, is this mimetype any use? application/octet-stream, for instance, really isn't. The text/html that the server sends in this case passes this check.

Then, given that we have a good mimetype, we look up a file extension for that mimetype, and find the .html extension in the registry.

Now things get messy. Windows determines how to open files based on the file extension. It has no real concept of mimetypes and they are not associated/determined from files when determining how to open them. So we generate an nsIMIMEInfo object based on the file extension. This guarantees that the file ends up with a file extension that gets it opened how the website would expect based on the mimetype. So we defer to the mimetype to determine what file extension that should be, because the extension we determine from the URL is often bogus (it's either missing or could be "php" or whatever) - on the web, mimetypes rule the roost.

For .html, on Windows we almost certainly find registry information on how to open it, because of course Firefox itself has registered as a handler to open these files.

On mac, I had a brief look but it seems that the implementation of GetMIMEInfoFromOS is a bit non-committal, and just returns a mime info object for text/html, without any extensions listed (!?) and then the JS code or the streamlistener must later decide "oh well, we'll use whatever we got given then".

If theory, I'd argue that the behaviour of Chrome, and our mac/linux implementation is wrong. ".exe" is not a valid extension for an HTML file, and the website claims this is an HTML file, so we should probably treat it like one (which we do on Windows).

In practice, I'm curious about why Chrome behaves as they do. It's possible they treat text/html with a download content-disposition or something the same way we treat application/octet-stream. Either way the practical fix here is to fix the mimetype sent by the server...
If Google have a reason for having it this way, or if we think we need to use safebrowsing to mark the download based on the file extension rather than the mimetype, to be honest I'm not 100% sure how we'd get to that place, because I'm not familiar with how we "normally" invoke safebrowsing.

Does that help? :-)

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(dlee)

(In reply to :Gijs (he/him) from comment #6)

For .html, on Windows we almost certainly find registry information on how to open it, because of course Firefox itself has registered as a handler to open these files.

Oh, and I forgot to say, we'll return a mimeinfo object that has the .html extension and text/html mimetype, and then we end up using that for the dialog, suffixing it on the .exe thing because we've (correctly) decided that that isn't a valid extension for text/html content.

(In reply to :Gijs (he/him) from comment #6)

Does that help? :-)

Yes! This is very clear, thank you for this very detailed explanation :)
I'll check with Google to see if them intentionally change the behavior of the server because of any security concern, so they can ensure Chrome shows an warning in the scenario. If that was just a mistake, I would say as long as the file type download protection sees is the same as the file type saved to disk, I'm fine with it.

Flags: needinfo?(dlee)
Has Regression Range: yes → ---
Keywords: regression
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.