Deserialization of Untrusted Data in com.jsoniter:jsoniter [CVE-2021-23441]

[RalphSteinhagen]

CVE-2021-23441 flagged here:

Description All versions of package com.jsoniter:jsoniter are vulnerable to Deserialization of Untrusted Data via malicious JSON strings. This may lead to a Denial of Service, and in certain cases, code execution.

References https://nvd.nist.gov/vuln/detail/CVE-2021-23441 https://snyk.io/vuln/SNYK-JAVA-COMJSONITER-1316198

Does somebody have a patch/fix for this that could be merged and then released? Any help would be much appreciated!

[dagnelies]

I just had a closer look at this CVE out of curiosity and I'm rather dumbfolded ...is it just me, or is it just plain nonsense?!

[plokhotnyuk]

While code snippets from snyk.io look harmless there are can be some real vulnerabilities:

1. DoS attack that exploits O(n)^2 complexity of parsing some classes (where n is number of input characters) like BigInteger/BigDecimal;
2. DoS attack that exploits OutOfMemory errors during parsing of some classes like BitSets;
3. DoS attack that exploits StackOverflow errors during parsing of deeply nested JSON objects/arrays (or recursive classes);
4. RCE attack that exploits the ability to parse unregistered class by type discriminator from the input.

I don't know if any of them exists for json-iterator yet.

An acceptable solution for possible DoS attacks would be introducing some configurable limits (max number of digits, max bitset value, max level of nesting, etc.) with reasonable defaults.

Here and here are examples of how DoS vulnerabilities of json4s library were tested with jsoniter-scala harness.

[plokhotnyuk]

I found more detailed samples here

[xsun12]

@plokhotnyuk

I found more detailed samples here

Telegram is not accessible from my part of the world. Can someone copy the detailed samples here?

[plokhotnyuk]

@xsun12 4_5960538858721381440.pdf

[dagnelies]

@plokhotnyuk I don't see why any of that is problematic. It's ridiculous. There is no DoS or any vulnerability inside this pdf. It's just calling the setters. It's just what setters are for, it's the expected behaviour and I think all other json libs works exactly like this. Anything else would seem strange to me.

Also, regarding the "potential" vulnerabilities, isn't the role of a vulnerability report to proove that there is one, instead of "well, maybe there is something, no idea though, I haven't any working example".

[dagnelies]

It would be nice if they would actually provide some real DoS or RCE example instead of alarming the world with unfounded claims and pure speculations.

PS: I'm not affiliated with this project in any way ...it just popped up in one of my projects as dependency alarm

PS @plokhotnyuk : Thanks for the link ...it's a pity that such a "CVE" is published without even being reviewed.