GitHub Portable with .7z.exe extension

[cliffporterx]

I wanted to advise on something I was seeing with security software with the Git releases available on:
https://github.com/git-for-windows/git/releases

When it comes to the portable versions, I have security software that is hitting on those files because the file extension ends in '.7z.exe'.
The reason the security software hits on this is because of the tactic of a double extension in Windows to make something that is made to look like something else, but it is actually an executable, which they call 'masquerading'. So something like Evilfile.doc.exe and things like that the software would hit on as suspicious. While it is not detecting it as malicious in this case, it is detecting it as suspicious simply due to it being an executable with a double file extension.

I can see that the files are signed and the exe is created using 7zip SFX. My guess is that the original packed file, such as 'PortableGit-2.22.0-64-bit.7z' is being repacked to the self extracting executable. However instead of creating it as 'PortableGit-2.22.0-64-bit.exe', it is creating it as 'PortableGit-2.22.0-64-bit.7z.exe' instead, probably by some way it is identified in the original config script being used to repack this.

I just wanted to advise of this, wanting to suggest to see if the script used to repack this can be updated to not retain the .7z in the middle, so it would create the file like 'PortableGit-2.22.0-64-bit.exe' instead. This should prevent the security software from detect it as a possible masqueraded file.

[dscho]

However instead of creating it as 'PortableGit-2.22.0-64-bit.exe', it is creating it as 'PortableGit-2.22.0-64-bit.7z.exe' instead, probably by some way it is identified in the original config script being used to repack this.

No. This is done on purpose, to indicate to users that they can also use 7-Zip to extract the files.

I am not sure that it is worth bending to security software's ideas of what we should use as file extension, and risk breaking users' scripts (that possibly might have come to rely on the exact file name that pretty much every single portable Git used since the first one was published).

[PhilipOakley]

Is there an option to change the first . (period/full stop/dot) character to an alternative to get past that heuristic, so maybe PortableGit-2.22.0-64-bit_7zip.exe or whatever is human readable, and avoids the problem that can occur in some (many?!) corporate environments? (Oh, I changed 7z to 7zip as well - for the humans who don't associate 7z with that application..)

[cliffporterx]

I would agree with PhilipOakley comment. I would have an understanding about some scripts but I brought this up since it has been becoming more often that the double extension trick has been attempted to be used in a lot of recent malware attacks.
As mentioned the security software doesn't block it immediately (unless it determines the file is malware anyway) but it will definitely call it out and alert warnings on it. Unfortunately because of what others are doing with the masquerading technique it then makes some legitimate software look like it is doing the same trick, thus why security software is starting to flag and warn when it sees something like this.

[dscho]

Is there an option to change the first . (period/full stop/dot) character to an alternative

Sure, but that changes the file name pattern, something I am loathe to do lest I break scripted setups that have long been working.

If we break the pattern, then we should just delete the .7z from the file name.

It will take two things:

• a PR to change this line

• a really convincing commit message that makes me believe that this is something I want to risk, something that won't upset too many users.

[PhilipOakley]

A further option, to cover a transition period, maybe to duplicate the file with an alternate, agreed, filename, so that both sets of folks can plan/implement their changes. It does double the storage size for the Portable resources, but not for the user, as long as they have selected the appropriate version.

Would still need a PR and convincing commit message ! !

[dscho]

A further option, to cover a transition period, maybe to duplicate the file with an alternate, agreed, filename, so that both sets of folks can plan/implement their changes. It does double the storage size for the Portable resources, but not for the user, as long as they have selected the appropriate version.

I would need some really good argument that convinces me. So far, I haven't heard anything convincing (@cliffporterx take that as a clear encouragement to try harder).

Would still need a PR and convincing commit message ! !

Indeed.

[assarbad]

@cliffporterx Having worked in the anti-malware industry until the beginning of this year for well over a decade I can tell you that you should never try to appease an AV by adjusting your behavior. Instead I advise you to report this as a false positive to the AV vendor whose product you chose. Also, you may want to reconsider your choice of product if someone seriously considers this a sensible heuristic.

Most AV solutions are rife with false positives and just like all detections these spread. But unlike detections of malicious software, which we want included, the news of something being a false positive doesn't spread equally throughout the AV industry and so these tend to stick around much longer (or never go away). If you look at VirusTotal you can tell that it's an insurmountable task for ISVs to contact all those vendors. More so because there is no unified way to contact them, let alone one place to contact them all.

[dscho]

Okay, I think the consensus is that this ticket can be closed without further work on the issue.