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.

[chadlwilson]

Thanks a lot @cowtowncoder . I have contacted NVD/NIST with the relevant information and am seeking to get https://nvd.nist.gov/vuln/detail/CVE-2022-42003 updated to reflect these micro-patch releases so people’s scanner noise goes away if they update to these (or via relevant BOMs).

Will follow up for the separate CVE fix backported to 2.12.x if I get a positive response/outcome.

[chadlwilson]

@DavidKorczynski I think we need coordinate better in future: my understanding was that a CVE would be filed, I’d be notified with id allocated (so I can update this issue, release notes), but CVE only made public once official release was out. But perhaps I am assuming there is a mechanism that does not exist between allocating an id and making it available for the public.

@cowtowncoder the mechanism definitely exists with MITRE to reserve and allocate a CVE independently of disclosure, which is normal practice. Indeed if one uses GHSA to raise ones security isues you can get GitHub to manage this process for you as a CVE Numbering Authority, as well as collaborate on the text in GitHub with those who raise the issue, leaving maintainers able to manage the disclosure alongside, or after a release is available.

Based on what I observed with the set of ossfuzz SnakeYAML vulns in the last few months and now this, the well intentioned and otherwise good work within ossfuzz is in some cases unleashing a torrent of noise on already limited OSS dev time due to the way our current generation of tools work (dependency checkers etc), complexity of dependency trees and then overreaction from certain ops/security folk who ignore important context and for some reason put blind trust in the CVE process (which is remarkably, err, subjective and subject to abuse IMHO).

Unfortunately this case does not seem like ‘responsible’ disclosure to me. I fear that if we as a community create noise like this, we take away from dev time (OSS and users alike) to actually address the most important security issues - instead replacing it with devs having to understand or explain risk severity, evaluate environmental context/feature usage yada yada, rather than just being able to upgrade and move on (ideally bot-and-test-automation assisted) - without having to think about whether one is affected or not.