xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 2 months ago

Last modified 7 weeks ago

#2088 closed defect (invalid)

Bitdefender Endpoint Security Tools

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 2.5
Component: core Version: 2.4.x
Keywords: Cc:

Description

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.

Attachments (2)

epconsole_2018-12-19_11-12-26.png (38.3 KB) - added by stdedos 3 months ago.
epconsole_2018-12-19_11-13-26.png (47.3 KB) - added by stdedos 3 months ago.

Download all attachments as: .zip

Change History (16)

Changed 3 months ago by stdedos

Changed 3 months ago by stdedos

comment:1 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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.

comment:2 Changed 3 months ago by 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
Last edited 3 months ago by stdedos (previous) (diff)

comment:3 Changed 2 months ago by Antoine Martin

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

comment:4 Changed 2 months ago by 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/

comment:5 Changed 2 months ago by 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.

  • r21440 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: 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.

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:6 in reply to:  5 Changed 2 months ago by 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.

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

comment:7 Changed 2 months ago by 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. :(

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:8 Changed 2 months ago by Antoine Martin

Resolution: invalid
Status: newclosed

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.

comment:9 Changed 2 months ago by 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.

comment:10 Changed 2 months ago by 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.

comment:11 Changed 2 months ago by stdedos

Thank you for the updates!

comment:12 in reply to:  8 Changed 2 months ago by 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?

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

Last edited 2 months ago by stdedos (previous) (diff)

comment:13 Changed 2 months ago by 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..

comment:14 in reply to:  13 Changed 7 weeks ago by 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)
Note: See TracTickets for help on using tickets.