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

[cowtowncoder]

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.

[cowtowncoder]

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.

[henryrneh]

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

[cowtowncoder]

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

[henryrneh]

@cowtowncoder thank you 👍

[DavidKorczynski]

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.

[henryrneh]

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?

[pjfanning]

@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.