AV picks up an infected file in openapi-generator-client.jar

[DwarvishGnome]

Description

I'm running Intego Virus Barrier on my Mac. I downloaded the latest JAR file as in the README description, but in a scan Virus Barrier said one of the files was infected.

Is this a false positive from my AV, or something more?

openapi-generator version

4.0.2

[jimschubert]

@DwarvishGnome Can you provide the sha1 hash of the file you've scanned?

The vulnerability described in your screenshot is CVE-2012-0507, should be resolved by JRE 7 critical security updates from what I can see in googling the exploit. The issue would have been a potential denial of service attack, described succinctly by Tomas Hoger:

The AtomicReferenceArray class implementation did not properly check if the array is of an expected Object[] type. A malicious Java application or applet could use this flaw to cause Java Virtual Machine to crash or bypass Java sandbox restrictions.

---

I've just downloaded directly from Maven Central and uploaded to Kasperky's online scanner (https://virusdesk.kaspersky.com/), and there are no threats detected:

I've also scanned with BitDefender and AVG locally, and neither of these found threats in the published jar.

Here are the sums from the above image to compare:

md5:

MD5 (openapi-generator-cli-4.0.2.jar) = e05f79c6044df31e434305e1cb4c7baf

sha1:

dd9467f01b40023b00f621326019b42295da8746  openapi-generator-cli-4.0.2.jar

sha256:

901fb1c35e355f340f8a882c0f5875bafd45919810eb7321beb5f645c090e91e  openapi-generator-cli-4.0.2.jar

You can also verify a jar from the maven repo by downloading the jar and signature:

https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/4.0.2/openapi-generator-cli-4.0.2.jar https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/4.0.2/openapi-generator-cli-4.0.2.jar.asc

Then, in the download directory run gpg --verify openapi-generator-cli-4.0.2.jar.asc

---

My guess is a false positive due to maybe your Java version or the configured heuristics in the virus scanner. This could be a mix of the use of AtomicReferenceArray<Object> in the Version class of the TzdbZoneRulesProvider, and loading the TZDB.dat file within that same parent class.

If you look at the code via a decompiler like JD-Gui, you'll see the class referenced in your screenshot has a lot of wording like "getRules" but also loads a TZDB.dat file (the contents are loaded into the Version type):

If I had to guess, the scanner is probably triggering this alert because there's a dat file being loaded directly into a type for which there was a CVE.

If you want to verify whether or not this dat file matches the dat file released with our dependent version of threetenbe (1.3.1), you can:

mkdir evaluation && cd evaluation
wget https://github.com/ThreeTen/threetenbp/archive/v1.3.1.zip
wget https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/4.0.2/openapi-generator-cli-4.0.2.jar
wget https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/4.0.2/openapi-generator-cli-4.0.2.jar.asc
gpg --verify openapi-generator-cli-4.0.2.jar.asc
jar xf openapi-generator-cli-4.0.2.jar
unzip v1.3.1.zip
cmp --verbose ./org/threeten/bp/TZDB.dat ./threetenbp-1.3.1/src/main/resources/org/threeten/bp/TZDB.dat

The last command will exit cleanly for an unmodified dat file. If you were to download the latest threetenbp TZDB.dat (2019a), you'd get a ton of differences in this file:

…
96537   0  31
96538 244  35
96539   2 234
96540  76  70
96541   0 155
96542 263  60
96543   2 123
96544  77 230
96545   0 114
96546  75 123
cmp: EOF on ./org/threeten/bp/TZDB.dat

If you run through any of these steps and find the scanner flags the jar again, you might want to reach out to Intego directly. I haven't worked with them but I had a false positive maybe 10 years ago on Windows, and was running Norton at the time… iirc they just requested a copy of the quarantined file.

---

@OpenAPITools/generator-core-team we may want to consider updating or removing our threetenbp dependency (see https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/pom.xml#L202) as it's only needed for Java 6/7 support.

[DwarvishGnome]

@jimschubert Thanks very much for your detailed response.

I computed the SHA1 hash by doing shasum -a 1 openapi-generator-cli.jar, and it returned dd9467f01b40023b00f621326019b42295da8746, so it's definitely the same download. My AV still flagged up the file.

I tried the steps you suggested above, but the scanner still flags the jar, so I've reached out to Intego.

I've got a support ticket with them, so I'll let you know what they say.

Thanks once again!

[cbornet]

@DwarvishGnome the CVE is about a bug in the JRE. Can you give us the Java version which is used during the scan ?

[wing328]

I did a scan on the JAR locally and don't see any issue. You may consider using the online generator for the time being: https://github.com/OpenAPITools/openapi-generator#33---online-openapi-generator

[wing328]

@jimschubert I've created https://github.com/OpenAPITools/openapi-generator/issues/3258 for tracking

[DwarvishGnome]

@cbornet Here's the output from the terminal

[ 16:17:02 ~]$ java -version openjdk version "12.0.1" 2019-04-16 OpenJDK Runtime Environment (build 12.0.1+12) OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)

[wing328]

If you still need help from us, let us know and we'll reopen the issue.

[DwarvishGnome]

@wing328 I got an email from Intego earlier, saying that the latest AV definitions shouldn't pick this up. Updated definitions, scanned again, and all was fine!

@cbornet @jimschubert Thanks for your help earlier this week

[wing328]

@DwarvishGnome 👌 Glad to hear the issue has been resolved for you.

If you're happy with OpenAPI Generator, please consider supporting our voluntary work via https://opencollective.com/openapi_generator

[jimschubert]

I want to say, I'm impressed by Intego. First, for obviously scanning for CVEs within jar files. And second, for resolving the issue in under a week.