Potential vulnerability in JSON deserialization
GrrrDog opened this issue · comments
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
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?
Class name check (whitelist) is a good solution.
Need a little help with naming:
Would the allowClass(String pattern) method name be a good one?
This issue appears to have been assigned CVE-2018-21234.
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?