Skip to content

Jackson Polymorphic Deserialization CVE Criteria

Jump to bottom
Tatu Saloranta edited this page Mar 7, 2022 · 10 revisions

What qualifies for a CVE report for Polymorphic Deserialization

This page outlines the criteria used for accepting problem described "On Jackson CVEs: Don't Panic!" -- that of possible security problems if:

  • Service accepts JSON content from untrusted senders AND
  • Service enables "Default Typing" feature (or uses equivalent @JsonTypeInfo with base type of java.lang.Object) AND
  • Service has one of 3rd libraries with "gadget" Java classes AND
  • Jackson version is 2.9.x or lower

then there may be a security issue to address by an addition to the class block list.

When such issues are reported, new checks have been added to Jackson versions 2.9 (later versions have separate prevention mechanism that does not rely on blocks) to prevent deserialization of these reported "gadget" types.

Problem with maintenance of block list

Originally reports covered widely-used Java libraries (like EHCache or Spring Web or Hibernate) and there were even one or two types found were include in (some versions of) JDK. These could be expected to be security vulnerabilities for multiple projects and as such worth blocking.

But maintaining these blocks and handling CVE id request, allocation and version releases has its cost -- and because Jackson 2.10 and later are not considered vulnerable in same sense, over time effort to keep adding to the block list has exceeded value for maintainers. For context, the current block list (Jackson-databind 2.9.10.6) contains about 90 specific classes across 30-40 libraries.

Why Jackson 2.10+ not considered vulnerable

The question of whether polymorphic deserialization gadgets should be considered for ANY Jackson versions is a tricky question since these attacks do NOT work against default configuration of ObjectMapper: developers must explicitly enable "Default Typing" (or use specific annotations on value classes to enable it). As such, strictly speaking these attacks should not truly qualify -- they may or may not apply, depending on specific usage of Jackson. This is unlikely most other CVEs where applicability is of "yes/no" style based on version.

However: given that originally some of these issues were accepted (they are security concerns for some subset of users, after all), it became necessary to consider WHY they were accepted. Reasoning the project ended up with is as follows:

  • While vulnerability requires users to take specific action, methods that enable behavior did not mention security concern -- so users/developers were likely to be unaware of security consequences

With that in mind, Jackson 2.10 was change substantially so that there are new method for enabling so-called Safe Default Typing, which requires "Allow List" approach to outline acceptable subtypes; instead of former global "Deny List" (aka "black list"). Allow lists are by their nature a safer approach; and in this case user is then responsible for specifying safe set of subtypes allowed. In addition to the new safe approach, all old Unsafe methods were changed to:

  1. Include Javadocs that explain why use of these methods is a potential security risk
  2. Be deprecated in Jackson 2.x; to be removed from Jackson 3.0.

This combination of changes allowed the change in acceptance (or lack thereof) of CVEs against Polymorphic Deserialization for different Jackson versions.

New criteria (from Sep 15, 2020): Notability

Starting on September 15, 2020, new blocks will only be added (and CVE ID allocated) for "gadget" types that are "Notable", which means inclusion in either:

  1. JDK version 1.8 (Java 8) or later (all valid types accepted, blocks added)
  2. Publicly available, "popular enough" artifact:
    • Must be listed on MvnRepository.com
    • Is depended on by at least 20 libraries (not including other components of the same framework, if part of larger set of artifacts)

Some of existing blocks do not fulfill this criteria but blocks that been added previously will not be removed simply due to lack of popularity (or accessibility).

One particular class of no-longer-accepted cases includes that of Application Server classes only available as part of AS installations -- unless they are accessible as artifacts via Maven Central (or similar publicly accessible and indexed Maven repos).

End of Jackson 2.9 support (31 Dec, 2020)

Due to availability of new minor versions (2.10.5 and 2.11.2 available as of Sep 2, 2020), no new releases of Jackson 2.9 are planned to be released, not even micro-patches, after end of 2020.

The last planned micro-patch release was 2.9.10.8, released 06-Jan-2021. While it is still possible that an exception could be made for some critical issue but there are no plans for regular addition to the block list beyond 2.9.10.8.

Criteria for possible extension (from January 01, 2021)

Although no systematic additions are considered beyond end of 2020, it is possible that specifically notable cases could be addressed. The minimum level that must be satisfied is that gadget type is included in:

  1. JDK version 1.8 (Java 8) or later
  2. Publicly available, very popular artifact:
    • Must be listed on MvnRepository.com
    • Is depended on by at certain number of libraries (not including other components of the same framework, if part of larger set of artifacts)
      • Until 31st Mar 2021: 200 libraries
      • Until 30rd Jun 2021: 500 libraries
      • Until 30rd Sep 2021: 1000 libraries
      • Until 31st Dec 2021: 2000 libraries

While additions may be accepted as per above criteria, Jackson team will not be filing for CVE IDs nor accept them against versions 2.10 and above. Submitters are free to report these to Mitre, against existing 2.9 and earlier relevant versions.

End of accepting CVEs for Polymorphic Deserialization

After end of 2021 (31st Dec, 2021), "Default Typing" style CVEs are no longer accepted regardless of what gadget types are used.

Clone this wiki locally