Potential vulnerability in JSON deserialization

[GrrrDog]

Current behavior

Jodd's Json parser supports polymorphic deserialization when setClassMetadataName is set.
If an application parses JSON with this configuration from an untrusted source, it could lead to remote code execution.
The problem is quite the same as in other Java JSON libraries.
Here you can read more:

• https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
• https://github.com/mbechler/marshalsec/blob/master/marshalsec.pdf

Expected behavior

At least, you should mention security-implication of usage setClassMetadataName, similar to Jackson databind

Steps to Reproduce the Problem

If necessary, I could send an example of JSON which lead to RCE

[igr]

True. Besides the documentation, I could add additional optional class name checks. For example, only to allow instantiation of classes from e.g. foo.domain.* (using wildcards).

wdyt?

[GrrrDog]

Class name check (whitelist) is a good solution.

[igr]

Need a little help with naming:

Would the allowClass(String pattern) method name be a good one?

[carnil]

This issue appears to have been assigned CVE-2018-21234.

[xtt5480446]

Current behavior

Jodd's Json parser supports polymorphic deserialization when setClassMetadataName is set. If an application parses JSON with this configuration from an untrusted source, it could lead to remote code execution. The problem is quite the same as in other Java JSON libraries. Here you can read more:

• https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
• https://github.com/mbechler/marshalsec/blob/master/marshalsec.pdf

Expected behavior

At least, you should mention security-implication of usage setClassMetadataName, similar to Jackson databind

Steps to Reproduce the Problem

If necessary, I could send an example of JSON which lead to RCE

Could you show me an example of JSON which lead to RCE?