High CVE's Present in karate-core

Two high-severity CVE’s are present in 1.2.0.RC1 of karate-core. My company has a strict policy that we are not permitted to use any open source projects that have vulnerabilities with a score >= 7.0. As a result, we will be unable to continue using Karate until the issue is resolved. I can’t say with certainty, but I would image that many large corporations have similar policies in place.

Evidence

The official OWASP site recommends using the Dependency-Check Maven plugin to scan projects for vulnerabilities. This plugin can be applied two ways, as shown below.

Method 1: At compile-time, scan all of the dependencies used by Karate.

1. Checkout this branch of Karate, which has been modified to include Dependency-Check.
2. Build the project by running mvn clean verify from the root.
3. Observe that the build fails with the message [ERROR] netty-transport-4.1.63.Final.jar: CVE-2021-37136, CVE-2021-37137

Method 2: Scan the karate-core library directly.

1. Download the sample karate-dependency project.
2. Unzip the pom.xml into a clean directory.
3. Build the project by running mvn clean verify from the root.
4. Observe that the build fails with the message [ERROR] karate-core-1.2.0.RC1.jar\META-INF/maven/io.netty/netty-transport/pom.xml: CVE-2021-37136, CVE-2021-37137

Analysis

Karate depends on io.netty:netty-transport:4.1.63.Final which is the subject of CVE-2021-37136 and CVE-2021-37137. Because karate-core is a shaded JAR, it inherits the CVE’s of any JAR’s which are packaged inside it. Thus, industry-standard scanners (such as Dependency-Check) will report that com.intuit.karate:karate-core:1.2.0.RC1 contains two CVE’s.

Proposed Solution

Required: Update Karate’s dependency list to include a newer version of Netty which does not have any open CVE’s. More specifically, I propose updating com.linecorp.armeria:armeria from version 1.8.0 to 1.12.0 or higher in karate-core.

Optional: Build and publish two versions of the karate-core JAR - one standard, and one shaded. Providing a non-shaded version of karate-core will allow users (like me) to optionally specify our dependencies at runtime. This adds some overhead to the Karate project but provides a future-proof solution. With a shaded JAR, the dependencies are tightly-coupled. So when a new CVE is discovered in a dependency, the shaded JAR inherits that CVE and there’s no way I can work around it. With a non-shaded JAR, I can mitigate the new CVE by explicitly declaring a newer version of the dependency in my POM.

Let me know your thoughts on the above, and I can start work on it.

[packleader]

Thanks for proposing a fix. I had intended to work on this, but I’ve been having issues with my PC and haven’t had time to fix them. I’ll try to take a look at the PR between now and Saturday and provide any feedback.

[ptrthomas]

1.2.0 released