[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #17653 [- Select a component]: Stats on compiler and breakdown of false positives in antivirus programs



#17653: Stats on compiler and breakdown of false positives in antivirus programs
--------------------------------------+-----------------
     Reporter:  ping                  |      Owner:
         Type:  task                  |     Status:  new
     Priority:  Medium                |  Milestone:
    Component:  - Select a component  |    Version:
     Severity:  Normal                |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |    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 > 3.9.0.5 - 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

 ping

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17653>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs