CVE-2020-36518 (High) detected in jackson-databind-2.12.6.jar

[mend-for-github-com]

CVE-2020-36518 - High Severity Vulnerability

Vulnerable Library - jackson-databind-2.12.6.jar

General data-binding functionality for Jackson: works on core streaming API

Library home page: http://github.com/FasterXML/jackson

Path to dependency file: /build.gradle

Path to vulnerable library: /hes/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.12.6/fac216b606c1086e36acea6e572ee61572ad1670/jackson-databind-2.12.6.jar

Dependency Hierarchy:

• ❌ jackson-databind-2.12.6.jar (Vulnerable Library)

Found in HEAD commit: 855081675ac79d33fb4d1461091556bf6b566f78

Found in base branch: main

Vulnerability Details

jackson-databind before 2.13.0 allows a Java StackOverflow exception and denial of service via a large depth of nested objects.
WhiteSource Note: After conducting further research, WhiteSource has determined that all versions of com.fasterxml.jackson.core:jackson-databind up to version 2.13.2 are vulnerable to CVE-2020-36518.

Publish Date: 2022-03-11

URL: CVE-2020-36518

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: FasterXML/jackson-databind#2816

Release Date: 2022-03-11

Fix Resolution: com.fasterxml.jackson.core:jackson-databind:2.12.6.1,2.13.2.1

---

• Check this box to open an automated fix PR

[kaituo]

from FasterXML/jackson-databind#2816: "I’m sure that the same issue existing in 2.12.x and 2.11.x. May I know the fixing plan ? if the issue can only be fixed by upgrading to 2.14.x, when do you plan to release this version ?" and https://www.whitesourcesoftware.com/vulnerability-database/CVE-2020-36518 , no fix does not seem to exist now. Will monitor this for now.

[robtimus]

To be honest, I don't see how this is a CVE for only Jackson when both Gson and JSON-B have the same issue.

I've created a small test program that creates a simple JSON string with only nested objects for any given depth, then tries with Jackson, Gson and JSON-B until there is a StackOverflowError.

public static void main(String[] args) throws Exception {
    testJackson();
    testGson();
    testJson();
}

private static void testJackson() throws IOException {
    final int maxDepth = 10_000;
    for (int i = 2000; i < maxDepth; i++) {
        String json = createJson(i);
        try {
            Map<?, ?> map = new ObjectMapper().readValue(json, Map.class);
            map.size();
        } catch (StackOverflowError e) {
            System.out.printf("Jackson: %d%n", i);
            return;
        }
    }
    System.out.printf("Jackson: no failure for depth %d%n", maxDepth);
}

private static void testGson() {
    final int maxDepth = 10_000;
    for (int i = 2000; i < maxDepth; i++) {
        String json = createJson(i);
        try {
            Map<?, ?> map = new Gson().fromJson(json, Map.class);
            map.size();
        } catch (StackOverflowError e) {
            System.out.printf("Gson: %d%n", i);
            return;
        }
    }
    System.out.printf("Gson: no failure for depth %d%n", maxDepth);
}

private static void testJson() {
    final int maxDepth = 10_000;
    for (int i = 2000; i < maxDepth; i++) {
        String json = createJson(i);
        try {
            Map<?, ?> map = JsonbBuilder.create().fromJson(json, Map.class);
            map.size();
        } catch (StackOverflowError e) {
            System.out.printf("Json: %d%n", i);
            return;
        }
    }
    System.out.printf("Json: no failure for depth %d%n", maxDepth);
}

private static String createJson(int depth) {
    StringBuilder sb = new StringBuilder(10000);
    for (int i = 0; i < depth; i++) {
        sb.append("{\"m\":");
    }
    sb.append("{}");
    for (int i = 0; i < depth; i++) {
        sb.append('}');
    }
    return sb.toString();
}

Unsurprisingly, it's not just Jackson that fails but the others as well. Gson fails later, but it still fails. JSON-B fails at around the same depth.

I even expect that most frameworks for unmarshalling XML, YAML, etc. have the same problem. Unless there is a max depth specified somewhere, the framework will fail.

[schlm3]

How can this become a CVE with a high rating?
DOS attack, really?
The above testcase receives the StackOverflow after about 500ms here. Means an attacker would get the error after that time, which seems not to be too high for me.
Minimal effort on flow control on the http level (which you need to have in place anyway) is enough to mitigate this.
Or do I miss something here?

[amitgalitz]

@kaituo Seems like this got fixed with 2.13.2.2 as updated here FasterXML/jackson-databind#2816. I later checked that Opensearch core also made the update already to fix this CVE. I'll include this fix in my PR to update to alpha1 qualifier shortly