Bitdefender Endpoint Security Tools

[totaam]

Issue migrated from trac ticket # 2088

component: core | priority: minor | resolution: invalid

2018-12-19 09:18:57: stdedos created the issue

---

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.

[totaam]

2018-12-19 09:19:07: stdedos uploaded file epconsole_2018-12-19_11-12-26.png (38.3 KiB)

[totaam]

2018-12-19 09:19:15: stdedos uploaded file epconsole_2018-12-19_11-13-26.png (47.3 KiB)

[totaam]

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.

[totaam]

2018-12-20 10:24:51: stdedos commented

---

Even Xpra-x86_64_Setup_2.3.4-20590.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

[totaam]

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

[totaam]

2019-01-20 20:23:37: stdedos commented

---

Xpra_Setup_2.5-[r21303](../commit/d4a0488a9091e4f56bc62ed70c40aca7c10c7778).exe is installing normally

I have tried all of:

Xpra-x86_64_Setup_2.5-[r21159](../commit/390e7e19304093f7fd927f679d83b3245d25e1ca).exe
Xpra-x86_64_Setup_2.5-[r21225](../commit/a4fcf75ebf2e74a633b2a2a7bf6b413710b228cc).exe
Xpra-x86_64_Setup_2.5-[r21244](../commit/926b28caa92a0380718288aad1bd2d9798a6a45e).exe
Xpra_Setup_2.5-[r21303](../commit/d4a0488a9091e4f56bc62ed70c40aca7c10c7778).exe
Xpra-x86_64_Setup_2.5-[r21322](../commit/64d8017a8770fc0cd2b4d161b7efbe830a80cfb7).exe
Xpra-x86_64_Setup_2.5-21398.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-21398.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/

[totaam]

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.

• 21440 was built on a windows-7 ultimate VM
• r21441 was built on a windows-10 VM
• r21442 was built on the usual windows-7 pro build VM
• r21443 was build on a windows 7 pro system
  (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: 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.

[totaam]

2019-01-21 21:28:38: stdedos commented

---

Replying to [comment:5 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.

• 21440 was built on a windows-7 ultimate VM
• r21441 was built on a windows-10 VM
• r21442 was built on the usual windows-7 pro build VM
• r21443 was build on a windows 7 pro system
  (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: 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?

[totaam]

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: #1528#comment:1 (no pywin32), py2app doesn't run on windows (we use it on macos) and bbfreeze is unmaintained. :(

[totaam]

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.

[totaam]

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.

[totaam]

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.

[totaam]

Thank you for the updates!

[totaam]

2019-01-22 14:57:47: stdedos commented

---

Replying to [comment:8 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?

• I guess for x32/x86-64 it's already mentioned:

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 think xpra/xpra-client is trivial also: Full Xpra vs Client only Xpra.
  (Is it "just" minus the server part, or there are other bits and pieces missing?)

• 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?

[totaam]

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..

[totaam]

2019-02-01 12:36:45: stdedos commented

---

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)

[totaam]

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.

[totaam]

2020-04-07 10:16:03: stdedos commented

---

Noiice :-D

[totaam]

Also detected as malware by Microsoft Windows Defender: #2781.