Optimize `UntypedObjectDeserializer` wrt recursion [CVE-2020-36518]

EDIT: related to to CVE-2020-36518 (see https://nvd.nist.gov/vuln/detail/CVE-2020-36518)

EDIT: Fix included in

• 2.14.0
• 2.13.3:
  • Was also included in 2.13.2.1 and 2.13.2.2 (see https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13); to be used with jackson-bom version 2.13.2.20220328
• 2.12.6.1: (see https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.12)
  • use with jackson-bom version 2.12.6.1.20220326

EDIT: included as one of Snyk’s “top-10 vulns of 2022” CVEs – see https://go.snyk.io/snyk-top-10-open-source-vulnerabilities-dwn-typ.html

---

Current implementation UntypedObjectDeserializer is relatively expensive for deeply nested Object and Array values as it uses recursion even for “vanilla” case (one where there are no custom List/array or Map deserializers). In practical terms it is possible to exhaust typical modest JVM memory with documents having about ten thousand levels of nestings, due to size of call stack from recursive calls.

NOTE: specifically this ONLY APPLIES if the target type is “untyped” or generic Collection<Object> / Map<String, Object> – it DOES NOT APPLY to cases where target is POJO (except if POJO itself has “untyped” property or properties).

Similar issue was already solved wrt JsonNode (see #3397), included in 2.13.0; this might show a way to approach this problem: by replacing simple recursion with iteration, either completely or at some inner levels.

Also note that it may ultimately be necessary to have lower-level constraints for streaming parser too, see: https://github.com/FasterXML/jackson-core/issues/637

Ideally it should be:

1. Possible to handle at least tens of thousands of levels of nesting (100k should be processable with 256M heap, say)
2. Have streaming level limits that – by default – block documents with more than limit we deem safe (less than 100k – perhaps 10k or something, to be determined).

This issue is specifically about (1) as (2) is about jackson-core.

[cowtowncoder]

Oh fucking great. Someone decided to file an CVE for this one.

Surely teaches me to file issues on things I want to work on – and then some Very Nice Person going to file an CVE to freak out everybody.

[cowtowncoder]

@Syed-Shahul-Hameed more that I have to spend time on answering this question slower the release is. As soon as I find time – this is a non-paid voluntary activity for me, alongside a real job and family – I will make a release.

In the meantime I just hope users will eventually push back on security tool vendors that cause all of this stress and fake alarm: Security Circus at its worst. This wrt general applicability – there is an actual potential problem, for some users and usage. But not an immediate generally applicable wide-scale thing like remote execution.