On Sat, Aug 10, 2019 at 7:32 PM Daniel Beck <[email protected]> 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. > > 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 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 +- -- 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/CAL4a10hcGOb5Xm8KAsmJifpYJmSkbXqhq54PB1aJrKYjr-w-qQ%40mail.gmail.com.
