Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Remove or extract default typing

See original GitHub issue

As a downstream project that depends on Jackson, Jackson’s default typing feature is a PITA. The feature, by design, enables remote code execution. Personally I don’t understand how all these CVE vulnerabilities that essentially say “Jacksons remote code execution feature allows remote code execution” come to exist, they aren’t vulnerabilities, they are Jackson working exactly as documented and intended. But it causes a pain for us because every time a new way to use Jacksons remote code execution feature to execute remote code is found, we get multiple notifications from people using and auditing our dependencies saying “OMG! PLAY FRAMEWORK HAS A SECURITY VULNERABILITY”. And surely given the incredibly wide use of Jackson, we’re not the only project that feels this.

I think the feature should be removed from the core of Jackson databind. Perhaps the necessary plug in points to make it possible to implement the feature by a separate module could be left behind, this would ensure that the people that really need the ability to shoot themselves in the foot still can - is there a Darwin awards for IT security? But this wouldn’t just make things easier for us (and Jackson itself), it will also protect users that don’t realise just how dangerous the feature is, because it will introduce friction, they won’t just be able to discover and enable the method, they’ll have to actually add a new dependency. Preferably the module would not even be related to FasterXML, so that automated scans and other reports wouldn’t associate the CVEs reported against it with sensible use of Jackson. I suggest a group id of: io.danger.will.robinson.

Issue Analytics

  • State:open
  • Created 5 years ago
  • Reactions:8
  • Comments:6 (5 by maintainers)

github_iconTop GitHub Comments

cowtowncodercommented, May 2, 2019

@jroper WDYT about #2195 – I have initial implementation ready and I think this would be a reasonable way forward in near term.

cowtowncodercommented, Mar 22, 2019

@jroper Ok. I am not sure I 100% understand, but maybe I can try to summarize challenges to see where we agree.

So, first, it would be important to be able to know for sure that a user is not using unsafe settings. This would help deal with security tools, vendors, to point out there is a way to tell that usage of specific version is safe. This is important for security-conscious users as well. I agree there of course.

But the problem in getting there is due to 2 dimensions:

  1. There are 2 vectors to enable vuln: “default typing” and “@JsonTypeInfo” with basetype of java.lang.Object (and small number of alternatives)
  2. Backwards compatibility requirements: 2.x vs 3.0

Starting with (2), simple immediate removal of functionality (or methods to enable it) should not be done in a minor release, ideally. But given that migration from 2.x to 3.0 will take literally years, doing nothing is not a good option either. At practical level I would be ok with something like “mark methods we do not want anyone to [be able to] use Deprecated in 2.10, pointing to alternatives, remove in 2.11”. This because I do think that there are sometimes cases where following SemVer is less valuable than “doing the right thing for users”. Without doing this there would not be easy upgrade path that improves security. With 3.0 we can start with clean slate regardless, iff we can find such combination.

But the tricky part, I think, is the (1).

Specifically I do not object to changing “ObjectMapper.enableDefaultTyping()” (and variations) to require passing of something that indicates allowed class names to use. I do have minor disagreement on whether Jackson ought to maintain blacklist (to me it seems that at least on short term, it should, although separated out in modular way). Perhaps answer there is a separate module that just contains implementation for Blacklist-backed verifier.

So far so good. But the problem is the annotation part. It is not so much that of configuring validator: I think mechanism used for “default typing” could suffice as the baseline. But what I worry about are users using @JsonTypeInfo on java.lang.Object property, where there is no simple way to break things in a way that is immediately obvious – there is no way to induce a compilation failure, and since type lookups are dynamic, failure (with version 2.11, or maybe even earlier) would come at runtime, at unpredictable time. Ideally users would have unit tests that would catch this, but knowing what I know I think there are enough users who do not have this to make it very painful for them, and by extension, Jackson maintainers (mostly me).

So. I would like to brainstorm the specific way to deal with:

  • 2.x users who use @JsonTypeInfo on java.lang.Object properties

What would be mechanisms to

  1. Configure new validator (per-mapper default, new annotation for validator to use for case of java.lang.Object base? Extending @JsonTypeInfo more difficult as it can’t refer to types defined in jackson-databind
  2. Specify exactly how things fail upon detecting missing configuration.
Read more comments on GitHub >

github_iconTop Results From Across the Web

How do you remove a default program association for file ...
Click on the Default Programs icon and then click on the Associate a file type ... Use File Type Doctor to choose default...
Read more >
Is there a type-level way to extract properties that have default ...
I want to extract the key names of properties in a class that have default values. Is this information available to the type...
Read more >
Jackson 2.10: Safe Default Typing - cowtowncoder - Medium
Safe Default Typing means that in addition to specifying the main existing criteria for default typing — which classes should automatically use ...
Read more >
Export or Import Default Application Associations
Generate a default app associations XML File; Add or Remove Default ... that application will appear as the default for that type, ...
Read more >
TypeScript — Extract/Unpack a Type from a Generic - ITNEXT
So now let's remove the redundant topping type and try our luck ... Notice that the cheeses are optional, and we have a...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found