CVE-2024-57699 raised against 2.5.0...2.5.1

[Sukramolas]

IT seems there is open CVE against the project since 2/6/2025:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-57699

Description
A security issue was found in Netplex Json-smart 2.5.0 through 2.5.1. When loading a specially crafted JSON input, containing a large number of ’{’, a stack exhaustion can be trigger, which could allow an attacker to cause a Denial of Service (DoS). This issue exists because of an incomplete fix for CVE-2023-1370.

This causes security fails in build automations.

[qwertychouskie]

Also affected by this issue on 4 Spring Boot projects.

[ccudennec-otto]

I've opened a PR to address this issue. At least the case described in the CVE seems to be fixed by this.

For everyone running into this CVE via Spring Security, you might want to comment on the issue in "com.nimbusd:oath-oids-sdk": https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/398/create-json-smart-shim-for-gradual#edit

I think they should migrate away from json-smart as this library is not well-maintained anymore according to the README.md.

[Sukramolas]

I've opened a PR to address this issue. At least the case described in the CVE seems to be fixed by this.

For everyone running into this CVE via Spring Security, you might want to comment on the issue in "com.nimbusd:oath-oids-sdk": https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/398/create-json-smart-shim-for-gradual#edit

I think they should migrate away from json-smart as this library is not well-maintained anymore according to the README.md.

If there is no action from maintainer, maybe you could do a fork with your fix for the community. Thank you for the PR!

[snieguu]

Today, I checked whether the application(spring based) I maintain is vulnerable, and here are my considerations. I crafted a malicious JWT, signed it, and used it to attempt an authorization request to an API. However, the following preconditions were required:

• The Authorization header containing the malicious JWT was too large, so I had to increase the maximum request header size on the application server. This would also need to be done on any reverse proxy server in a real-world scenario.

• I had to sign the JWT, which required access to the private key. This effectively means compromising the entire application, as possession of the private key allows an attacker to craft tokens with access to potentially any resource, posing a much greater risk than just a DoS attack.

In other words, thanks to the Defense in Depth principle, we can generally consider this an unlikely attack vector for a correctly configured application.

Another case is if someone use this lib for parsing eg request payloads :)

[Sukramolas]

Spring boot dependencies and test seem to contain jsonpath 2.9.0, which in turn brings in json-smart 2.5.1. However looking at where it is used in spring boot

https://github.com/search?q=repo%3Aspring-projects%2Fspring-boot%20minidev&type=code

seems it is only used in tests and not runtime on any parsing.

But at the moment, automated security scans flag this as vulnerability, and rank it HIGH. Snieguu - it is as you say, it is unlikely that it happens in well controlled and configured app, but developers have liberty to do whatever they want.

[vdzhuvinov]

Thanks everyone for the quick turnaround of this.

I have critique for the CVE. It should have mentioned that an easy fix was available to downstream deps, using the JSONParser.LIMIT_JSON_DEPTH option. Maybe the author(s) weren't aware of this.

@ccudennec-otto The Nimbus OAuth / OIDC SDK applied that fix in 11.22.1:

https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/494/

[ccudennec-otto]

Can you please get a release of json-smart 2.5.2 to maven central? They would be smart.

@UrielCh has mentioned in the PR comments that he needs support from Sonatype to push the new release to Maven Central.

[chrismonster]

@vdzhuvinov good point - however json-smart is also a transitive dependency of SpringBoot, and implementing the workaround might be tricky there - it also explains the great interest in 2.5.2 :)

[ArloL]

It is a CVE that allows an attacker to potentially trigger a Denial of Service attack. So the attacker does not really care how many { she needs as long as the attack is successful. The risk scenario for an attack like this is definitely different for every application and needs to be taken into account by their maintainers individually as the CVE process can't do that for you.

The detailed scores of CVE-2024-57699 are

• Base Score: 7.5 HIGH
• Impact Score: 3.6
• Exploitability Score: 3.9
• Attack Vector (AV): Network
• Attack Complexity (AC): Low
• Privileges Required (PR): None
• User Interaction (UI): None
• Scope (S): Unchanged
• Confidentiality (C): None
• Integrity (I): None
• Availability (A): High

The fact that it is easily exploited over the network, without privileges and with low complexity explains the high rating.

And that rating wants to inform us about how urgently we need to evaluate our services - if we are running any critical infrastructure. For example the Mirai Botnet Attack or the 2007 cyberattack on Estonia were cases where such critical infrastructure was attacked using DoS - so it's no laughing matter anymore. Software has eaten the world and stupid things like a lot of { can really mess your day up if your hospital can't do your operation because their health care management software is down.

So in essence the CVE process does not tell you how urgently you need to update. It tells you how urgently you should evaluate this CVE and whether it's an issue for your specific scenario. And if you're annoyed by that - I get it. It's a lot. But that is what we get for developing the systems that run peoples lives. I embrace that responsibility and want to do good by the people using our stuff and am sure you do too ☺️ In most cases this means no rush to get 2.5.2 out to production. But it means we want to follow through and in a reasonable manner make sure it reaches most running services.

[Sukramolas]

@vdzhuvinov good point - however json-smart is also a transitive dependency of SpringBoot, and implementing the workaround might be tricky there - it also explains the great interest in 2.5.2 :)

That is likely 99% of the interest! Now to tell team who owns json-path:2.9.0 that they need to up their dependencies to 2.5.2 as well.

[jpsla94]

Just upgraded json-smart to 2.5.2 still getting a vulnerability detected in my security report. Are extra steps necessary?

[vdzhuvinov]

Just upgraded json-smart to 2.5.2 still getting a vulnerability detected in my security report. Are extra steps necessary?

@jpsla94 What reporting tool are you using?

[jpsla94]

Just upgraded json-smart to 2.5.2 still getting a vulnerability detected in my security report. Are extra steps necessary?

@jpsla94 What reporting tool are you using?

@vdzhuvinov nexus iq

[THausherr]

sonatype... but it worked yesterday?!

2025-02-13T15:54:02.4691880Z [ERROR] Failed to execute goal org.sonatype.ossindex.maven:ossindex-maven-plugin:3.2.0:audit (audit-dependencies) on project tika-fetcher-microsoft-graph: Detected 1 vulnerable components:
2025-02-13T15:54:02.4693074Z [ERROR]   net.minidev:json-smart:jar:2.5.2:compile; https://ossindex.sonatype.org/component/pkg:maven/net.minidev/json-smart@2.5.2?utm_source=ossindex-client&utm_medium=integration&utm_content=1.8.1
2025-02-13T15:54:02.4694243Z [ERROR]     * [CVE-2024-57699] CWE-674: Uncontrolled Recursion (8.7); https://ossindex.sonatype.org/vulnerability/CVE-2024-57699?component-type=maven&component-name=net.minidev%2Fjson-smart&utm_source=ossindex-client&utm_medium=integration&utm_content=1.8.1
2025-02-13T15:54:02.4694365Z [ERROR] 

[frankf16]

Same for me, using OWASP Dependency Check:
On Feb 12th, upgrading to 2.5.2 fixed the alert - then, on Feb 13th, CVE-2024-57699 was reported also against 2.5.2.

[Sukramolas]

it passes with Fortify and WhiteSource (as of 2/14). I would say that the tools are too eager to flag it; as NVD database still lists only to 2.5.1 and it has not been properly analyzed yet. Granted, most places have uphill battle trying to convince security that it has been fixed.