Rejecting CVEs for jackson-databind

[Daniel Beck]

Hi,

To the best of my knowledge, the feature affected by the many recent CVEs in jackson-databind is opt-in: It requires an #enableDefaultTyping() call, or an @JsonTypeInfo on a field with a wide open type.

In such cases, the CVE rules[1] state that the vulnerability is not in the library, but in the software using the library in an unsafe manner:

> If there is a way to use the library, protocol, or standard without being vulnerable: Assign a CVE ID to each affected codebase or product and continue to INC1
>
> If the using the library, protocol, or standard requires the product to be vulnerable: Assign a single CVE ID and continue to INC1

After the most recent CVE, mostly in an attempt to understand why they are assigning CVEs for these issues in the first place, I contacted MITRE and asked that they start rejecting these CVEs because of the above.

Part of their response reads as follows:

> Here, the maintainer of the jackson-databind product (GitHub user cowtowncoder) is adding the CVE IDs to the applicable GitHub issue pages, and has not contacted MITRE to ask for any CVEs to be rejected. We do not want to reject CVE IDs in cases where they are in active use by a software maintainer, regardless of whether there might be arguments both ways about whether they are consistent with the CNA Rules.

While there have been recent discussions such as [2], I haven't seen any references to the CVE counting rules, or awareness that, apparently, cowtowncoder could simply opt out of getting CVEs assigned to jackson-databind for this class of vulnerability -- so I thought I'd point this out, in case there's interest.

Given the current approach to dealing with these issues -- blacklisting --, it seems pragmatic to document in the library that this feature is inherently unsafe, and should not be used on externally controlled data (if it isn't already). Then jackson-databind could consider all new gadget discoveries to not be vulnerabilities, and their blacklisting to be hardening.

This way, consumers of the library that are not using these features don't have to do the update dance every few weeks (at least for scanners using only CVEs as data source), while the security concerns are made clear to anyone using the feature.

WDYT?

Regards
Daniel

1: https://cve.mitre.org/cve/cna/rules.html#Appendix_C
2: https://groups.google.com/d/msg/jackson-user/BMOPx_hkdqQ/d4OH384fBQAJ

[Tatu Saloranta]

On Sat, Aug 10, 2019 at 7:32 PM Daniel Beck <m...@beckweb.net> wrote:
>
> Hi,
>
> To the best of my knowledge, the feature affected by the many recent CVEs in jackson-databind is opt-in: It requires an #enableDefaultTyping() call, or an @JsonTypeInfo on a field with a wide open type.

Hi Daniel! I have been meaning to actually send an email to the list
regarding this issue, and my thoughts & plans. I'll add a short
version of that below.

So, yes. In hindsight, it would probably have made sense not to
requested CVE ids when security researchers reported the first
deserialization gadgets, given that doing so set a precedent that has
lead to current problem of never-ending update process.
At the same time, I think that bringing more visibility into this
problem was a good thing, at least initially.

But what was done was done and the critical question is how to proceed.

The most practical way forward, in my mind is to:

1. Add appropriate warnings into existing methods that enable
vulnerable handling. I have made some changes, but could use
contributions, suggestions, for good wording, places to indicate this
in useful context.
2. Deprecate these methods for 2.10 along with above-mentioned
warnings, to be removed from 3.0 (Semantic Versioning does not allow
removal until major version)
3. Add safe replacements that allow "default typing" but with
user-provided limitation mechanism, only providing opt-in approach
out-of-the-box. See
https://github.com/FasterXML/jackson-databind/issues/2195
- Question: should replacement methods use different naming from
old methods, to allow easier searching for "dangerous" methods,
without having to check argument lists?
4. If new CVEs are accepted, only include versions pre-2.10 (that is,
up to and including 2.9)

Of these (1), (2) and (3) have been done, and included in 2.10.0.pr1.
Policy change of (4) is something I have thought about.

The reason I think it is better to allow CVE ids, but only include
earlier versions as susceptible, is to have some consistency, and to
keep track of gadgets.
Although to be honest, by the time 3.0.0 is out maybe practicality of
block-listing of gadgets has diminished and it makes more sense not to
actually maintain it, or keep track, and instead consider there to be
unknown set of potential gadgets.

Thoughts?

-+ Tatu +-

[Daniel Beck]

> On 11. Aug 2019, at 04:45, Tatu Saloranta <ta...@fasterxml.com> wrote:
>
> Thoughts?

Thanks for your response. These plans sound great!

> - Question: should replacement methods use different naming from
> old methods, to allow easier searching for "dangerous" methods,
> without having to check argument lists?

I see this is already implemented as #activateDefaultTyping. Making it easier to discover/ban unsafe methods seems like a major benefit.

(I tried to let more active Jackson users respond first, but this doesn't seem like a topic of much interest on this list.)

[Tatu Saloranta]

On Sat, Sep 14, 2019 at 6:58 AM Daniel Beck <m...@beckweb.net> wrote:

> On 11. Aug 2019, at 04:45, Tatu Saloranta <ta...@fasterxml.com> wrote:
>
> Thoughts?

Thanks for your response. These plans sound great!

>     - Question: should replacement methods use different naming from
> old methods, to allow easier searching for "dangerous" methods,
> without having to check argument lists?


I see this is already implemented as #activateDefaultTyping. Making it easier to discover/ban unsafe methods seems like a major benefit.

Yes, I figured that there isn't that much downside and that many larger codebases still rely on textual search for finding out usages.

 

 

(I tried to let more active Jackson users respond first, but this doesn't seem like a topic of much interest on this list.)

Unfortunately participation does ebb and flow a lot. But I appreciate giving others a chance to have a say, that is a good practice to get wide coverage of opinions.

So: as of now, I plan on starting to request that submitters only include versions up to 2.9, and in case 2.10 is added try to rectify classification. My understanding is that maintainers at Mitre are pretty good in this, and are aware of challenges of classifications, metadata.

Also: on somewhat related news -- as per my email on `jackson-dev`, I decided try try out Tidelift (https://tidelift.com), and sign up as maintainer of (some) Jackson packages. They provide managed subscriptions to sort of curated OSS library versions, and share some of revenue with maintainers.

My hope is that this could help both me (and other lead maintainers that might be interested in joining, f.ex for Kotlin, Scala, Java 8 date/time, Hibernate, JSON Schema) spend more on doing OSS and also due to work I have to do as "Lifter" -- add more version metadata, release notes, issue notes, security notifications, clarify licensing, vuln disclosure practices -- hopefully improve Jackson usage experience by subscribers (at first I assume, bigger companies).

So I think that there will be more documentation on expected flow of security disclosures, too.

-+ Tatu +- 

 

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/64DD9CFD-4CBF-4928-B62B-C48441B62DBC%40beckweb.net.