EqualsVerifierBugException.class falsely triggers certain virus scanners as containing "Exploit-ByteVerify" trojan

[9numbernine9]

What steps will reproduce the problem?

Attempting to use EqualsVerifier >= 3.0 in a corporate environment that uses McAfee VirusScan using the latest definition files will detect the EqualsVerifierBugException.class file inside of the equalsverifier JAR downloaded from Maven Central as containing a virus.

What is the code that triggers this problem?

The compiled version of EqualsVerifierBugException, i.e. EqualsVerifierBugException.class.

What error message or stack trace does EqualsVerifier give?

N/A

What did you expect?

My employer's virus scanner to not be a piece of junk.

Which version of EqualsVerifier are you using?

3.1.2 (or at least I'm attempting to).

Please provide any additional information below.

Hello!

Firstly, I want to say that I love EqualsVerifier and use it everywhere that I can. Secondly, I apologize in advance if this issue reads like something that a crazy person would write; as I feel like a crazy person debugging the problem, maybe that is appropriate.

Since version 3.0 of EqualsVerifier, my company's virus scanner (McAfee VirusScan Enterprise) detects any of the JARs downloaded from Maven Central as containing the Exploit-ByteVerify virus (I'll also state here that I KNOW this is wrong, and I'm sure you know it too). You can see this yourself by downloading the JAR for 3.0 from Maven Central and uploading it to VirusTotal (here's a recent analysis if you just want to look at the results). You'll notice Exploit-ByteVerify error beside the "McAfee" entry in the results. (Also note that you can't just send the URL to VirusTotal, otherwise it won't use the McAfee engine - you must upload the actual file). You can also repeat this process for any version since 3.0 and get the same end result.

Now, at this point, you're probably thinking "poor ol' 9numbernine9, he's really lost it this time!" but please bare with me as I delve into this craziness and explain what I think is happening.

Exploit-ByteVerify is a circa-2003 trojan that exploits a bug in versions of Internet Explorer from around that time. In fact, Symantec has published a useful analysis of the bug that you can read all about here and I encourage you to do so. If you read the report, you'll notice that it makes reference to a whole bunch of specifically named Java class files that the exploit uses:

• Blackbox
• PermissionDataSet
• PermissionSet
• URLClassLoader
• VerifierBug

Now, if I'm working for McAfee and have had the required somewhere-between-partial-and-full lobotomy required to work on their AV signatures, I would probably read that report and write some signatures that check for those class names. In my case, that appears to be what has happened: McAfee's signature for Exploit-ByteVerify checks for THE STRING VerifierBug inside of Java class files and flags them as being infected if present.

Don't believe me? I understand - extraordinary claims require extraordinary evidence and whatnot. So, you can verify this yourself by writing your own "McAfee-Certified Virus!". Here's the code:

public class VerifierBug {}

Fiendish, right? Compile that code and upload the class file to VirusTotal and, lo and behold, McAfee says that it's a virus (here's my upload).

At this point you're probably wondering: how does this relate to EqualsVerifier? Go back to that list I mentioned a few paragraphs ago; unfortunately for me, EqualsVerifier contains a class called EqualsVerifierBugException, and since the compiled version of that class contains the string VerifierBug in it, McAfee now says that it's a virus.

Because I love EqualsVerifier and really want to continue using it, I'm only left with a few options:

1. Get McAfee to fix this signature (no idea how to even go about this)
2. Disable my virus scanner at work (this won't go over well)
3. Get my company to change virus scanners (not going to happen any time soon)
4. Submit a PR to the equalsverifier project that renames the problematic class.

I have opted for option #4 and hope that you will see it in your heart to accept my PR. :-) (It's #230 ) If you have questions or want more information, please let me know.

[jqno]

Hi Matt!

Are you kidding? Of course I'll merge your PR! I've run into this issue twice before and had no idea how to fix it. I just decided to ignore it because it's such an obvious, blatant false positive and I figured there's nothing I can do. I'm happy to learn that there actually is something I can do, and it's as easy as merging a simple PR!

Thank you for doing all the research on this. As a reward for your effort, I'll make a release right away.

Also, I very much enjoyed your write-up. :)

[jqno]

Version 3.1.3 is syncing with Maven Central as we speak.

[jqno]

I've just uploaded the artifact to VirusTotal, and it says it's clean now ! 🎉

[9numbernine9]

Amazing! Thank you @jqno ! I'm glad that you enjoyed the write-up, and somewhat relieved to see that I might not be the only person to run into this bizarre issue. I feel as if I have gained a small bit of my sanity back today. :-)

[jqno]

Haha :). In fact, I was even contacted by Sonatype because their systems also detected the virus in my artifact on Maven Central. I sent them a link to this issue to give them a heads-up.
Also, I got this tweet yesterday: https://twitter.com/codecholeric/status/1079052682004963330

[9numbernine9]

Amazing. 😆
I hope Sonatype has an easy way of flagging and ignoring false positives within their systems for versions [3.0.0 .. 3.1.2]!