Add check in primitive value deserializers to avoid deep wrapper array nesting wrt UNWRAP_SINGLE_VALUE_ARRAYS [CVE-2022-42003]

TL;DNR:

Fix included in:

2.14.0 once released (until then, 2.14.0-rc1 and rc2)
2.13.4.2 micro-patch (jackson-bom 2.13.4.20221013). (NOTE: 2.13.4.1/2.13.4.20221012 have an issue that affects Gradle users)
2.12.7.1 micro-patch (jackson-bom 2.12.7.20221012)

(note: similar to #3582 )
(note: originally found via oss-fuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51020)

Implementation of methods like _parseBooleanPrimitive (in StdDeserializer) uses idiom:

            if (ctxt.isEnabled(DeserializationFeature.UNWRAP_SINGLE_VALUE_ARRAYS)) {
                p.nextToken();
                final boolean parsed = _parseBooleanPrimitive(p, ctxt);
                _verifyEndArrayForSingle(p, ctxt);
                return parsed;
            }

to handle unwrapping. While simple this exposes possibility of "too deep" nesting and possible problem with resource exhaustion in some cases. We should change this similar to how #3582 was handled.

Methods to update (and regression test):

_parseBooleanPrimitive()
_parseBytePrimitive()
_parseShortPrimitive()
_parseIntPrimitive()
_parseLongPrimitive()
_parseFloatPrimitive()
_parseDoublePrimitive()
_parseDateFromArray() (maybe?)

Also note that method _deserializeWrappedValue() implements checks although cannot quite be called as-is.
Similarly, BeanDeserializer._deserializeFromArray() at around line 632 has similar checks.

@cowtowncoder

Hello dear @cowtowncoder,

I am Henry from Code Intelligence. First of all thank you for your quick fixes of this issue!

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51020

Is this issue regarded as a security issue? If yes, we are thinking about applying CVE for it, so the community knows about it and will update to the latest version of jackson-databind.

Thank you for your fixes and support for OSS-Fuzz!

Best regards,
Henry

@henryrneh

@henryrneh Same as #3582 (see my comments there).

@cowtowncoder

@cowtowncoder thank you 👍

@henryrneh

This issue was found by a fuzzer written by the Ada Logics team and is part of an ongoing security assessment. @henryrneh can you please ensure the issues you report are found by the fuzzers written by your team (https://github.com/google/oss-fuzz/blob/master/projects/jackson-core/JsonFuzzer.java and https://github.com/google/oss-fuzz/blob/master/projects/jackson-databind/ObjectReaderFuzzer.java) then we'll take care of those from our fuzzers.

I already canceled the application. We will do our best to try not to apply CVEs for fuzz targets written by AdaLogics, however we will need some assitance or notification by you to know who wrote which fuzz target, because OSS-Fuzz is not designed to support this, maybe you can use some special prefix in the fuzz target name so it's more obvious for us so we can filter it out?

@henryrneh

@henryrneh the disclosure in https://nvd.nist.gov/vuln/detail/CVE-2022-42003 should really have been delayed until jackson-databind v2.14.0 was released. The RC should have been given a good chance to be tested and an orderly release of 2.14.0 done when it is ready. Now we risk having people clamouring for an early release of 2.14.0.

@pjfanning

@pjfanning -- @AdamKorcz and I applied for this CVE and was done in coordination with the current audit of jackson. We coordinated this with Tatu in terms of agreeing we should apply for CVEs for these issues.

@pjfanning

Our OWASP scan just ran into this finding for our use of jackson-databind 2.13.3. We are very hesitant to go to an RC of 2.14 (and of course fully understand that this issue cannot change the release plans for 2.14, so we will not join the crowd that is pushing for an "early release of 2.14" @pjfanning :-)).
But since 2.13 is an actively maintained branch according to https://github.com/FasterXML/jackson#active-developed-jackson-2x-branches, I assume a fix will be made available there as well? Any activities or maybe even an ETA for that?

@jgoeres

@jgoeres @alzimmermsft are you even using the UNWRAP_SINGLE_VALUE_ARRAYS option?

@vdotjansen

They updated the CVE as the description changed from "In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled." to "In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. Additional fix version in 2.13.4.1 and 2.12.17.1".

But they forgot to update the CPE, therefor it will still match the new versions.

@vdotjansen What you possibly need to know (but may not?) is that descriptions as they appear in NVD come from and are mastered in MITRE rather than the NVD -- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42003 . Likely someone has updated it there; possibly via the CNA/submitter or with a form submission to MITRE itself and the description has flowed through to the NVD in feeds. That won't do anything for CVSS scores, CPEs, affected versions etc. These parts are mastered in the NVD and MITRE knows nothing about them. When changes flow through from MITRE, they tend to get marked as

This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.

So they didnt "forget" to update the CPE, they just haven't updated it yet.

I e-mailed them because I mostly look at the CPE, did not notice the change in the description at first.

NVD haven't actually replied to my original email, and it's still marked as being under analysis due to this description change - so they will probably get to it. I'd advise being patient. I've included the details already about the CPEs needing adding as well as the adjustment to the versions. I've done this a few times before, and it has always worked ... eventually.

Have they been informed about 2.13.4.2 as well?

@radarsh It's not strictly necessary for them to have every version listed unless it's at the boundary of a fix or vuln, but since it is still in their analysis queue, they will likely add that version at the same time.

The process is slow and manual and non-transparent, but I suspect 100 of us emailing them isn't going to make it go any faster....

@vdotjansen

@vdotjansen What you possibly need to know (but may not?) is that descriptions as they appear in NVD come from and are mastered in MITRE rather than the NVD -- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42003 . Likely someone has updated it there; possibly via the CNA/submitter or with a form submission to MITRE itself and the description has flowed through to the NVD in feeds. That won't do anything for CVSS scores, CPEs, affected versions etc. These parts are mastered in the NVD and MITRE knows nothing about them. When changes flow through from MITRE, they tend to get marked as

I knew that there was data shared between MITRE and NVD, but did not know which part came from MITRE although I did know at least the CPE's are managed by NVD.

NVD haven't actually replied to my original email, and it's still marked as being under analysis due to this description change - so they will probably get to it. I'd advise being patient. I've included the details already about the CPEs needing adding as well as the adjustment to the versions. I've done this a few times before, and it has always worked ... eventually.

Like I said I only checked the CPE.

The process is slow and manual and non-transparent, but I suspect 100 of us emailing them isn't going to make it go any faster....

You are correct and I should have checked here first. My e-mail was send before I noticed your message here. We should not all send an e-mail you are correct. I should have checked here to see, but I think it is better to send mails by 2 different people then 0 mails, as they need to know this. Next time I will check the issues to see if someone already send a mail. Me posting here that I also send an e-mail is hoping there will not be more e-mails towards them about this :)

NIST/NVD have got back to me after reviewing the publicly available info and are updating the affected versions right now.

I am working with the assumption that all 2.11.x and earlier versions are also affected, but if the UNWRAP_SINGLE_VALUE_ARRAYS feature in question was only added some time along the way in a 2.x version the CVE mapping could be more specific. Possibly a bit moot given the other vulnerabilities likely to exist in those earlier versions anyway...

The CVE affected versions for this issue are finally updated and should be correct now. There was a bit of back-and-forth with the NIST/NVD folks and a weekend delay, but got there eventually...

@chadlwilson

@chadlwilson Maybe I just need to wait for another database update but 26 hours ago my Anchore vuln scanner reported this was fixed via 2.13.4.1 and now my scanner is reporting that NVD says CVE-2022-42003 has no fix available. This is directly contradictory to what is displayed on NIST? I am thoroughly confused.

{
            "feed": "vulnerabilities",
            "feed_group": "nvd",
            "fix": "None",
            "nvd_data": [
                {
                    "cvss_v2": {
                        "base_score": -1.0,
                        "exploitability_score": -1.0,
                        "impact_score": -1.0
                    },
                    "cvss_v3": {
                        "base_score": 7.5,
                        "exploitability_score": 3.9,
                        "impact_score": 3.6
                    },
                    "id": "CVE-2022-42003"
                }
            ],
            "package": "jackson-databind-2.13.4.1",
            "package_cpe": "None",
            "package_cpe23": "cpe:2.3:a:fasterxml:jackson-databind:2.13.4.1:*:*:*:*:*:*:*",
            "package_name": "jackson-databind",
            "package_path": "/root/.gradle/wrapper/dists/gradle-7.5.1-bin/7jzzequgds1hbszbhq3npc5ng/gradle-7.5.1/lib/plugins/jackson-databind-2.13.4.1.jar",
            "package_type": "java",
            "package_version": "2.13.4.1",
            "severity": "High",
            "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42003",
            "vendor_data": [],
            "vuln": "CVE-2022-42003",
            "will_not_fix": false
}

@RetroDreams

@RetroDreams not sure. Seems like something you'd need to check in your Anchore deployment.

Bump jackson-databind to 2.13.4.2

chore(deps): use version 2.12.7.20221012 of com.fasterxml.jackson:jac…

Fix FasterXML#3590

Backport fix: wire CVE-2022-42004/42003 guards into actual call paths…

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

Add check in primitive value deserializers to avoid deep wrapper array nesting wrt `UNWRAP_SINGLE_VALUE_ARRAYS` [CVE-2022-42003] #3590

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Sunbelt Computer Software

PL/B Language Development and Support

Add check in primitive value deserializers to avoid deep wrapper array nesting wrt UNWRAP_SINGLE_VALUE_ARRAYS [CVE-2022-42003] #3590

Description

Activity

cowtowncoder commented on Sep 6, 2022

henryrneh commented on Sep 9, 2022

cowtowncoder commented on Sep 9, 2022

henryrneh commented on Sep 9, 2022

DavidKorczynski commented on Sep 12, 2022

henryrneh commented on Sep 12, 2022

pjfanning commented on Oct 5, 2022

DavidKorczynski commented on Oct 5, 2022

jgoeres commented on Oct 5, 2022

pjfanning commented on Oct 5, 2022

35 remaining items

chadlwilson commented on Oct 14, 2022

vdotjansen commented on Oct 14, 2022

chadlwilson commented on Oct 14, 2022

chadlwilson commented on Oct 19, 2022

RetroDreams commented on Oct 19, 2022

chadlwilson commented on Oct 19, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Add check in primitive value deserializers to avoid deep wrapper array nesting wrt `UNWRAP_SINGLE_VALUE_ARRAYS` [CVE-2022-42003] #3590