Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2023-5072 - Denial of Service in JSON-Java versions up to and including 20230618. #789

Open
elrob opened this issue Oct 13, 2023 · 31 comments

Comments

@elrob
Copy link

elrob commented Oct 13, 2023

https://nvd.nist.gov/vuln/detail/CVE-2023-5072

GHSA-rm7j-f5g5-27vv

@johnjaylward
Copy link
Contributor

Relates to #758, #759, #771, #772

@stleary
Copy link
Owner

stleary commented Oct 13, 2023

@elrob Thanks for letting us know. As @johnjaylward posted, it seems to me that both vulnerabilities have been addressed and it is only necessary to cut a new release. I don't think any additional code changes are needed.

@TimoBuechert
Copy link

TimoBuechert commented Oct 13, 2023

@stleary can you already tell when the new release with the fix will be created?
Thank you very much!

@stleary
Copy link
Owner

stleary commented Oct 13, 2023

Yes, the new release will come out later today.

@Bhavitha-Chava
Copy link

Hi @stleary, Could you pls let me know when we can expect the release? Is there a lower version that we can use to avoid hitting this vulnerability

purejava added a commit to purejava/keepassxc-proxy-access that referenced this issue Oct 14, 2023
@stleary
Copy link
Owner

stleary commented Oct 14, 2023

Release 20231013 is available, and is the earliest version that fixes the vulnerability. Have patience, it can take some time before it appears in the Maven repo.

@lhazlewood
Copy link

@stleary was it strictly necessary to require JDK 8 for this release? 20230618 was still JDK 7 compatible, but 20231013 is not.

@stleary
Copy link
Owner

stleary commented Oct 15, 2023

@lhazlewood It was not strictly necessary.
How important is this to you?
What version of Java do you use?
Can you upgrade to Java 8?

@stleary
Copy link
Owner

stleary commented Oct 15, 2023

@elrob @TimoBuechert Release 20231013 is now available in the Maven public repository.

@lhazlewood
Copy link

@stleary I maintain a library that is used with both Java and Android, and we support JDK 7 (at the moment) mostly for Android's purposes (which uses org.json APIs). That requirement for us is going away shortly however, and I did find a workaround using maven profiles to default to 20231013, with an override to 20230618 when compiling on JDK 7 for the time being.

@PayBas
Copy link

PayBas commented Oct 16, 2023

Haven't tested it thoroughly yet, but our main issue is that 20231013 seems to be included in the vulnerable versions in our Nexus Lifecycle tool:
image

Not sure if it's an administration error, or if they feel that 20231013 doesn't actually fix the vulnerability.

I'll try to contact SonaType to see whats up.

Update: opened support ticket:

https://nvd.nist.gov/vuln/detail/CVE-2023-5072 is marked as: "JSON-Java versions up to and including 20230618"
The developers assert that is has been resolved in version 20231013 #789

But Nexus IQ/Lifecycle says:
Recommendation
There is no non-vulnerable upgrade path for this component/package. We recommend investigating alternative > components or a potential mitigating control.
Version Affected
[20070829,20231013]

Any reason why SonaType would mark this specific version as vulnerable?

Update 2: apparently there's a dedicated place to submit corrections. So I've done so.
https://ossindex.sonatype.org/component/pkg:maven/org.json/json@20231013 will hopefully no longer be marked as vulnerable soon.

@stleary
Copy link
Owner

stleary commented Oct 16, 2023

@PayBas Thanks for checking. Perhaps they found a different way to recreate the problem.

@lhazlewood
Copy link

If there is to be another release for this, would it be possible to build with JDK 7? My maven profile workaround didn't work as I expected. If not, I'll understand, but I thought I'd ask in case it wasn't too difficult a request to entertain.

@PayBas
Copy link

PayBas commented Oct 16, 2023

@stleary it seems to have worked.

https://ossindex.sonatype.org/component/pkg:maven/org.json/json@20231013

This version of json has no known vulnerabilities! 🎉

@stleary
Copy link
Owner

stleary commented Oct 16, 2023

The CVE still appears to be under analysis, but hopefully it will be cleared soon, too.
https://nvd.nist.gov/vuln/detail/CVE-2023-5072

@stleary
Copy link
Owner

stleary commented Oct 16, 2023

@lhazlewood Yes, this can be done. Will the same code in a different repo work for you?

@lhazlewood
Copy link

@stleary how do you mean different repo?

@stleary
Copy link
Owner

stleary commented Oct 17, 2023

@lhazlewood It has not been decided yet. Might be a different repo that is published to Maven and tracks JSON-Java but is Java 7 compatible, or #741 might be reverted, which could get complicated. Do you have any thoughts or concerns about either option?

@johnjaylward
Copy link
Contributor

johnjaylward commented Oct 17, 2023

@lhazlewood It has not been decided yet. Might be a different repo that is published to Maven and tracks JSON-Java but is Java 7 compatible, or #741 might be reverted, which could get complicated. Do you have any thoughts or concerns about either option?

I think it would be best if we could make a java6 branch based off the tag for release 20230618. Then we would backport any PRs that are related to a CVE (like #759 and #772). The version for the branch would stay at a base value of 20230618, but we could point release it for security fixes like 20230618.001 to issue a fix for this CVE.

The master branch could then stay as supporting Java 8+ while only minimal required changes happen on the java6 branch for security issues.

Does that work for you @stleary ?

@lhazlewood
Copy link

@stleary @johnjaylward that sounds like a nice option if possible!

@johnjaylward
Copy link
Contributor

@stleary , here is an example of what the PR would look like if we created the java6 branch in this repo

johnjaylward#2

@stleary
Copy link
Owner

stleary commented Oct 17, 2023

@johnjaylward Your idea sounds like a good approach and probably the least disruptive of the options. What do you think this would look like in the Maven repo?

@johnjaylward
Copy link
Contributor

johnjaylward commented Oct 17, 2023

Should add the point releases under the java 8 releases

in Maven it should show:

  1. 20231013 (java 8+)
  2. 20230618.001 (java6+ with latest security fixes)
  3. 20230618 (java 6+ without security fixes)

Screenshot_20231017_181330_Firefox

@nathan454
Copy link

@stleary , here is an example of what the PR would look like if we created the java6 branch in this repo

johnjaylward#2

@stleary When can we expect backport for 20230618 ? I think @johnjaylward approach sounds ok

@stleary
Copy link
Owner

stleary commented Oct 25, 2023

@nathan454 Are you working on the same project as @lhazlewood, or is this a new request?

@nathan454
Copy link

@nathan454 Are you working on the same project as @lhazlewood, or is this a new request?

new request
I'm also using this version and I support a library that needs to maintain support for java 7

@johnjaylward
Copy link
Contributor

@nathan454 Are you working on the same project as @lhazlewood, or is this a new request?

new request I'm also using this version and I support a library that needs to maintain support for java 7

Why is there a requirement for Java 7? Is this for older Android support, or some other reason?

@alenamor7
Copy link

Hi @johnjaylward,
please correct me if I'm wrong: CVE-2023-5072 is fixed in the 20230618.001 version, but is not fixed in the newest 20231013 version? We still have a vulnerablity in the project even though the newest 20231013 version is used. Thanks

@johnjaylward
Copy link
Contributor

20231013 should be the fixed version. we decided to NOT point release 20230618 at this time.

@stleary
Copy link
Owner

stleary commented Nov 8, 2023

@johnjaylward I have been thinking about that. Now that Hacktoberfest is over, is there any reason why we could not do a point release of 20231013 that is compiled with Java7?

@johnjaylward
Copy link
Contributor

I don't see an issue with it. Would just need to update the deployment yml to compile to java7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants