Xpra: Ticket #2088: Bitdefender Endpoint Security Tools

Bitdefender Endpoint Security Tools after "An update process has been completed successfully.Product version: 6.6.7.99. Engines version: 7.78724 (12155221)", started recognizing the installers from the following files as Malware

Xpra-x86_64_Setup_2.5-r21225.exe Xpra-x86_64_Setup_2.5-r21159.exe

I have verified the hashes (but not the signatures) of the files.

I understand that it's not your fault, and that they are heuristics etc; however, if there is something you could do (or have changed) would be nice to fix it. Unfortunately Bitdefender Endpoint Security Tools does not give the "analyse" option, or anything of the sorts.



Wed, 19 Dec 2018 09:19:07 GMT - stdedos: attachment set


Wed, 19 Dec 2018 09:19:14 GMT - stdedos: attachment set


Wed, 19 Dec 2018 17:56:01 GMT - Antoine Martin: owner changed

Can you figure out at which revision this problem started? Can you paste the warning messages in text form? (they are truncated at the moment in the screenshot)

My best guess is #1988. This cannot be reverted, it saves a lot of time when installing and some disk space.


Thu, 20 Dec 2018 10:24:51 GMT - stdedos:

Even Xpra-x86_64_Setup_2.3.4-r20590.exe is failing:

C:\Program Files\Xpra\Audio_Devices.exe is malware of type Gen:Variant.Fugrafa.840

Unfortunately, BEST is ... the worst in this. So, apart from the above representative message, the other one is:

C:\Program Files\Xpra\Audio_Devices.exe is malware of type Gen:Suspicious.Cloud.4.dO0@aOEgVzgi

I believe you can see enough for the messages; basically, it likes nothing executable (whether it's "named" .exe or not)

Since there are so many variants (and I already tested the oldest available from the Beta), I would appreciate if you asked me a specific version to test.

And the official version fails too:

C:\Program Files\Xpra\Audio_Devices.exe is malware of type Gen:Variant.Fugrafa.840

Fri, 18 Jan 2019 17:54:26 GMT - Antoine Martin:

Please try the 32-bit builds and let me know if those are also detected as malware.


Sun, 20 Jan 2019 20:23:37 GMT - stdedos:

Xpra_Setup_2.5-r21303.exe is installing normally

I have tried all of:

Xpra-x86_64_Setup_2.5-r21159.exe
Xpra-x86_64_Setup_2.5-r21225.exe
Xpra-x86_64_Setup_2.5-r21244.exe
Xpra_Setup_2.5-r21303.exe
Xpra-x86_64_Setup_2.5-r21322.exe
Xpra-x86_64_Setup_2.5-r21398.exe

with verified gpg signatures also. The installer-under-test is in-between versions that are getting detected, so, I would assume it is a packer issue (?). Probably that Fugrafa-thing was using the same packers? Or something regarding architecture (?).


Some side notes: Xpra-x86_64_Setup_2.5-r21398.exe: Still recognized as malware

Some detection samples: https://www.virustotal.com/en/file/03106d334c35191161ecf204a30c0f3efa37dd9c5599011ff5266774f356fee8/analysis/1547632697/ https://www.virustotal.com/en/file/d76c7c3761ee481cbfd5cbe8d81d15b7bcb4a04468bfd660000239022cdfe842/analysis/1547632719/


Mon, 21 Jan 2019 14:49:14 GMT - Antoine Martin:

The installer-under-test is in-between versions that are getting detected, ...

I really don't understand what that means.

I can't discount the possibility that the build host has been compromised so this should allow us to see more clearly: please try the latest builds I have uploaded.

(the chances that every one of those got compromised by the same malware is pretty much non-existent since some of those systems sat unused for almost a year)

Alternatively, you could even build your own xpra from source: wiki/Building/MSWindows, it's really quite easy nowadays.

As for changing the packer, we use cx_Freeze, it's been problematic on more than one occasion but there aren't any other options that I know of.


Mon, 21 Jan 2019 21:28:38 GMT - stdedos:

Replying to Antoine Martin:

The installer-under-test is in-between versions that are getting detected, ...

I really don't understand what that means.

It would be really weird if r21244 is infected, r21303 is not infected, and then r21322 is infected again, given that everything is built on the same system, in order.

I can't discount the possibility that the build host has been compromised so this should allow us to see more clearly: please try the latest builds I have uploaded.

(the chances that every one of those got compromised by the same malware is pretty much non-existent since some of those systems sat unused for almost a year)

I have verified signatures and hashes for all installation packages. All of them appear "infected" (with the same strain: Gen:Variant.Fugrafa.840). However, after when r21442 they all started appearning "more" infected: Installation usually froze at Config_info.exe. After trying r21442, even Audio_Devices.exe appears infected (for all installations).

I would prefer if there was an x32 counterpart (built respectively) to verify. I believe this further verifies my conclusion: It's either a packer issue, or an "architecture" issue ... or both of them.

Alternatively, you could even build your own xpra from source: wiki/Building/MSWindows, it's really quite easy nowadays.

I guess x32 builds are good enough ... Shouldn't it be so, regardless of server?

As for changing the packer, we use cx_Freeze, it's been problematic on more than one occasion but there aren't any other options that I know of.

I assume this has come up one way or another https://docs.python-guide.org/shipping/freezing/, so probably add +1 to cx_Freeze issues?


Tue, 22 Jan 2019 05:22:07 GMT - Antoine Martin:

It would be really weird if r21244 is infected, r21303 is not infected, and then r21322 is infected again, given that everything is built on the same system, in order.

Those are not built on the same system. The 32-bit builds use a different build VM.

All of them appear "infected"

Then I am very confident that this is bogus, unless MSYS2 itself is compromised.

However, after when r21442 they all started appearning "more" infected: Installation usually froze at Config_info.exe.

All exes use the same packer. There are different sizes for the exe, depending on what cx_freeze decides to bundle in - the smaller ones don't trigger but the bigger ones do. It looks like one of the library triggers it, and it is now included in those.

I guess x32 builds are good enough ... Shouldn't it be so, regardless of server?

32-bit builds are a tad slower when it comes to decoding video, but since client computers usually have a lot of power to spare compared to servers, this should not be a problem.

I assume this has come up one way or another ​https://docs.python-guide.org/shipping/freezing/, so probably add +1 to cx_Freeze issues?

Yeah. We used to use py2exe before they added python3 support then we switched to cx_freeze, pyinstaller and py2exe can't work since xpra 2.0: ticket:1528#comment:1 (no pywin32), py2app doesn't run on windows (we use it on macos) and bbfreeze is unmaintained. :(


Tue, 22 Jan 2019 05:38:56 GMT - Antoine Martin: status changed; resolution set

BTW, you can also use the python3 installers, those don't seem to trigger the false positives. (and they're also built on the same system!)

I've submitted false-positive samples to f-secure and bitdefender through their websites.

I'm closing the ticket as invalid because there is no malware in those files.


Tue, 22 Jan 2019 11:20:47 GMT - Antoine Martin:

Got a response from f-secure, here's the gist of it: We have identified the issue as a False Positive, which will be resolved in an upcoming database update via Automatic updates.


Tue, 22 Jan 2019 14:13:06 GMT - Antoine Martin:

Received from bitdefender: We have received an answer from our Virus Analysis Labs. The file is clean and detection should be removed in the next couple of updates.


Tue, 22 Jan 2019 14:51:22 GMT - stdedos:

Thank you for the updates!


Tue, 22 Jan 2019 14:57:47 GMT - stdedos:

Replying to Antoine Martin:

you can also use the python3 installers


I meant to ask for sometime (although I have no idea what is the "preferred" method of asking "generic questions":

There are multiple versions for windows (xpra/xpra-client,x32/x86-64,py2/py3). I (probably) understand what is the difference, however: How should I pick?

(Is it "just" minus the server part, or there are other bits and pieces missing?)

I think I've heard that some things are missing in Python3 ... but in what context? "Missing things" are missing indeed, or they just use Python2 stuff?


Tue, 22 Jan 2019 15:10:57 GMT - Antoine Martin:

I meant to ask sometime (although I have no idea what is the "preferred" method of asking "generic questions":

The mailing list is the preferred medium, because it is easily searchable. (information can easily get buried in ticket comments)

I think xpra/xpra-client is trivial also: Full Xpra vs Client only Xpra.

Correct.

(Is it "just" minus the server part, or there are other bits and pieces missing?)

Just the server part.

What about py2/py3? I think I've heard that some things are missing in Python3 ... but in what context? "Missing things" are missing indeed, or they just use Python2 stuff?

Not much missing now: #1568. The server needs a bit more work, the client needs a new session-info graph tab, etc..


Fri, 01 Feb 2019 12:36:44 GMT - stdedos:

Fix for BEST was contained sometime between

Product version: 6.6.7.106. Engines version: 7.79259 (12469649) (29.01 12:01)

, and

Product version: 6.6.7.106. Engines version: 7.79301 (12477116) (31.01 23:45)

Tue, 07 Apr 2020 09:00:06 GMT - Antoine Martin:

Summary: this is a false positive.

f-secure said: We have identified the issue as a False Positive, which will be resolved in an upcoming database update via Automatic updates.

bitdefender: We have received an answer from our Virus Analysis Labs. The file is clean and detection should be removed in the next couple of updates.


Tue, 07 Apr 2020 09:16:02 GMT - stdedos:

Noiice :-D


Sat, 23 Jan 2021 05:41:53 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2088