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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/43D7E4A1-7139-44DA-9C72-3FCB179934AA%40beckweb.net.
