[CVE-2022-42003] A Denial of Service (DoS) vulnerability in com.fasterxml.jackson.core:jackson-databind

[abstractj]

Describe the bug

Our security scanner on Keycloak reported a CVE coming from quarkus-jackson that might be worth to consider upgrading in the upcoming releases. Below, you can find more details.

Overview

com.fasterxml.jackson.core:jackson-databind is a library which contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. At the moment

Affected versions of this package are vulnerable to Denial of Service (DoS) in the _deserializeWrappedValue() function in StdDeserializer.java, due to resource exhaustion when processing deeply nested arrays.

NOTE: This vulnerability is only exploitable when the non-default UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled.

Remediation

Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.14.0-rc1 or higher.

References

• Chromium Bugs
• Documentation
• GitHub Commit
• GitHub Issue

Detailed paths

• Introduced through: org.keycloak:keycloak-quarkus-server-app@999-SNAPSHOT › org.keycloak:keycloak-quarkus-server@999-SNAPSHOT › io.quarkus:[email protected] › io.quarkus:[email protected] › com.fasterxml.jackson.core:[email protected]

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @geoand, @gsmet

[sberyozkin]

@abstractj
Not sure if Quarkus can depend on RCs, especially if the fix is expected to be backported.
By the way, please consider reporting such issues at [email protected] in the future instead, see New Issue/Report Security Vulnerability, thanks

[abstractj]

@sberyozkin thanks, but from my understanding https://github.com/quarkusio/quarkus/security/policy applies only to embargoed CVEs, or security vulnerabilities into the codebase, things that were not publicly disclosed yet. CVE-2022-42003 is public knowledge and can be detected by most of the dependency scanners.

[sberyozkin]

Sure, even if it is a public CVE, its visibility just gets increased.

[famod]

If I'm not mistaken, Quarkus is not affected OOTB because it doesn't activate UNWRAP_SINGLE_VALUE_ARRAYS.

Can anyone confirm? @geoand maybe? Thanks!

[geoand]

That is indeed true @famod - we don't activate that and we don't even expose a property for users to activate it - although of course users can configure their ObjectMapper in any way they see fit.

[tsaarni]

By the way, please consider reporting such issues at [email protected] in the future instead, see New Issue/Report Security Vulnerability, thanks

Sure, even if it is a public CVE, its visibility just gets increased.

Hi @sberyozkin!

I personally think it would be better to deal with known vulnerabilities in open like @abstractj did by submitting this issue. Some reasons to keep CVE discussions open:

1. The purpose of CVEs is to draw attention to the vulnerabilities, so that users can evaluate the risk that they are facing.
2. Users can evaluate their risks better if they have access to discussions like this thread. They can get better understanding if the vulnerability is exploitable in the particular software and under which conditions etc....
3. Like @abstractj mentioned, scanners already report known vulnerabilities and this information is also publicly available in various online resources such as https://deps.dev/maven/io.quarkus%3Aquarkus-jackson.
4. Forbidding CVE discussions in open is not likely going to prevent malicious users from getting informed about the vulnerabilities from the other sources.

I hope these reasons could be considered and that Quarkus would allow publicly discussing about known vulnerabilities / CVE in future as well :)

[sberyozkin]

@tsaarni Hi, no one is disallowing or planning to disallow it and I'm sure users will be opening such public issues. It is better IMHO though not to draw everyone's attention to CVEs - we have a dedicated channel for taking care of such issues where Quarkus security team and Red Hat security team are listening, Red Hat team might decide to change the impact of the given CVE, etc. But it is indeed a public CVE so we let users decide how they want to report it
thanks

[gsmet]

I personally think it would be better to deal with known vulnerabilities in open like @abstractj did by submitting this issue. Some reasons to keep CVE discussions open

Well, while I agree that once a CVE is in the open, we can discuss it in the open, I'm not sure it's wise to get issues for all the CVEs that get reported out there. It will be a gigantic maintenance burden for us.

Anyway, for the time being, we will wait for a Final version of Jackson. By default, we don't use the aforementioned option so it's really to the users to decide if they are affected and if they want to take the risk to use a non final version.

Dependabot will take care of the upgrade automatically when a Final version is out.

[chadlwilson]

Looks like dependabot took care of this in #28550 - this BOM contains the micro patch release.

[gsmet]

Fixed in #28550 .

Will be included in 2.13.3.Final released tomorrow.