…g depth can be converted

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree I think there should be a reasonable default set. and people need to override it if they need more depth.

@cleydyr Sorry, my preference of not enforcing a default limit was not the best idea. Can you set a non-negative default value instead? ChatGPT suggests several hundred, which sounds reasonable to me.

What problem does this code solve?
Fixes CVE-2022-454688
A stack overflow in the XML.toJSONObject component of hutool-json v5.8.10 allows attackers to cause a Denial of Service (DoS) via crafted JSON or XML data.

Risks
Moderate. This is a breaking change, although it is unlikely that any users are parsing XML nested more than 512 levels.

Changes to the API?
No

Will this require a new release?
Yes

Should the documentation be updated?
No

Does it break the unit tests?
No, new unit tests were added

Was any code refactored in this commit?
No

Review status
APPROVED

Starting 3 day comment window

@stleary The JSONML class is used to (quoted from the class Javadoc):

convert an XML text into a JSONArray or JSONObject, ...... using the JsonML transform.

As such, this class can be in scope of the above CVE, or a similar future CVE that has not yet been created.

I think wherever XML parsing is used in this library, this vulnerability should be addressed.

Those further fixes can be added in a future patch release - although delaying those fixes may result in the upcoming release to be still marked as vulnerable.

A number of people have raised the valid point that JSONML and JsonObject/Array should have this protection as well.
No objection if anyone wants to address this, to be included in the next release.
We don't have an equivalent to XMLParserConfiguration, so something will have to be done about that - either add parser config types or come up with some other way to configure the parsers. My preference would be to add new parser config types, but I am open to other approaches. See #722

Personally I'd like a fast release to address the CVE, if the XML parser fix resolves it. tor. 9. feb. 2023 19.00 skrev Sean Leary ***@***.***>:

Should be later this week.

Hi there, very quick check. A week has passed (from last comment, that release should be later this week). Do you guys have any ETA of this release? 🙏

Normally, I wouldn't push it but as one of issues have quite high CVSS score, it is kind of a deal for us :-)

Same here, we're considering alternatives because of the critical score.

I can release it now, so ETA = today

Released, and should appear in the Maven repo in the next few hours.

Its in Maven Central! Thank you everyone!

Its in Maven Central! Thank you everyone!

I received this vulnerability when using jackson-core but I don't see anything updated so far. Can you provide the link to the maven update? Thanks.

jackson-core-2.14.1.jar
CVE-2022-45688

A stack overflow in the XML.toJSONObject component of hutool-json v5.8.10 allows attackers to cause a Denial of Service (DoS) via crafted JSON or XML data.

I don't see any libraries called Hutool in the dependency analyzer.

There are a few issues around this vulnerability:

1. The NIST page for the CVE originally listed the hutool as the only source (CPE) of the vulnerability; however, both hutool and the org.json library have a similarly vulnerable implementation.
2. Recently, the NIST page added the CPE for the original package (json-java_project:json-java). However, the affected versions clause Up to (excluding): 20220924 is incorrect, it is still vulnerable in 20220924.
3. After the above NIST database update, the OWASP dependency scanning tool started to emit false positives, as it identified many unrelated packages as matching the CPE json-java_project:json-java. The issue with the false positives was fixed in the OWASP dependency tool version 8.1.1
4. I expect that the NIST page will eventually be updated, as the CVE-2022-45688 vulnerability was fixed and a new release version 20230227 was published today.

Suggestions:

1. Make sure you use the latest version of the OWASP dependency scanner.
2. If you use the org.json package directly, update to the new version.
3. If you use the org.json package as a transitive dependency, then either:

• await a new version of the libraries you directly use (and suppress the vulnerability until then), or
• add the new org.json version as a direct dependency, and make sure that the version conflict is resolved in favour of the new version

4. If you use a library that contains a repackaged ("shaded") version of the org.json package, or a library that has a similar but independent implementation (like hutool), then you depend on the maintainer of that library - hopefully a new version of that library is released soon, to include the fixes.

Excellent write-up, I followed all the steps and this worked great. Thank you and I appreciate it.

dependencyCheck v 8.1.1
org.json v 20230227
dependencyCheckAnalyze gives

json-20230227.jar (pkg:maven/org.json/json@20230227, cpe:2.3:a:json-java_project:json-java::::::::) : CVE-2022-45688

no other versions of org.json are being referenced

dependencyCheck v 8.1.1 org.json v 20230227 dependencyCheckAnalyze gives

json-20230227.jar (pkg:maven/org.json/json@20230227, cpe:2.3🅰️json-java_project:json-java::::::::) : CVE-2022-45688

no other versions of org.json are being referenced

Like @TamasPergerDWP commented, I think the problem is that NIST DB has not been updated yet.