Opened 4 years ago

Closed 4 years ago

#17653 closed task (not a bug)

Stats on compiler and breakdown of false positives in antivirus programs

Reported by: ping Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Hi Guys

There is a disturbing trend in programs released over the last two years. I would really like your input on the issue.

It seems that gcc and windows compilers both exhibit the same behaviour when compiling certain files. The behaviour hardly shows up in modern antivirus programs, but rather when running an older antivirus program. There are numerous opens source projects that get flagged as Crypt.Xpack.Gen virus or some other virus. It doesn't matter if it was compiled with gcc or visual studio.

Here is a brief list of projects I have detected Crypt.Xpack.Gen issue with.

  • Arduino 1.6.5 and higher - open source
  • Tomahawk music player 1.8.0 and higher - open source
  • Filezilla > - open source
  • Chrome 47 and higher - open source
  • Free Download Manager > 3.9.3 - open source
  • Claws Mail 3.13 - open source
  • gpg4win - open source
  • qmmp 0.8.5 and higher - open source
  • taudioconverter 0.9.8 and higher - open source
  • putty 0.6.6 - open source
  • wireshark > 1.11.3 - open source
  • git 2.6.2 and higher - open source
  • vlc > 2.1.5 - open source
  • rufus > 1.2.0 - open source
  • torbrowser 5.0.4 - open source

This list is not exhaustive. The gut punch is that tor, gpg4win and claws should not be in this list fullstop.

Now my rationale on this is why tolerate even one false positive? Sure, antivirus vendors can be notified to allow your code, but the problem becomes a major foobar when everyone starts doing this. Monkey see, monkey do. Already with everyone moving to VS2012 and higher the problem becomes more prevalent. But what is more concerning is did gcc follow Redmond's trends or vice versa, because the same dll and lib packing is exhibited in gcc, that when scanned on a windows machine, flags as a virus.

So newer antivirus don't detect a thing, but then is that really a good idea? Sounds like a future backdoor for malicious code that mimicks the structure of a false-positive and can easily slip past your antivirus without you noticing.

Surely we should be progressing and retrogressing in compiler security, and not allowing anything to be compiled with a similar structure to a virus. Allowing that to happen opens the door to a world of false-positives effectively giving people a placebo and telling them to trust you.

I have tested all the above programs, and with every one there is a dramatic turning point where false positives do not exist. Each is reflected by the version number, so there is a way forward, because at one time dll's and libs were not packed in such a nefarious way. The version number all point to the trend starting around 2014 for gcc and visual studio.

What is sad is that torbrowser 504 gets flagged on omni.ja for an HTML/Crypted.Gen
So sure you tell us to trust it, but then every other dev on every other project claims the same thing about their code thereby unleashing a sea of false-positives onto the cyber landscape.

Perhaps tor needs to roll back to an earlier version of gcc and its build tools and then go about bullet proofing that toolchain for future use.

Thank you for your consideration


Child Tickets

Change History (2)

comment:1 Changed 4 years ago by teor

Component: - Select a componentTor Browser
Owner: set to tbb-team

Hi ping, thanks for reporting this issue.

I think antivirus false positives are a problem with antivirus software (and poor detection methods) rather than open-source programs and toolchains.

We use reproducible builds and signed downloads to avoid viruses being embedded during our build process. We certainly don't rely on antivirus programs.

comment:2 Changed 4 years ago by gk

Resolution: not a bug
Status: newclosed

I think, as teor said, this is an issue for the antivirus folks. We use reproducible builds to defend against this problem as well. So, this is not a bug in the things we ship. Rather, we already have a solution in place. ;)

Note: See TracTickets for help on using tickets.