-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
JSON parsing should detect embedded \0
values
#759
Conversation
A better solution might be to use -1 instead 0 to represent EOF everywhere, which of course means changing `char` variables to `int`. The solution here is enough to solve the immediate problem, though. Fixes stleary#758.
What problem does this code solve? Risks Changes to the API? Will this require a new release? Should the documentation be updated? Does it break the unit tests? Was any code refactored in this commit? Review status Starting 3-day comment window. |
\0
when parsing JSON objects.\0
values
There probably is going to be a CVE for the DoS issue, so you might want to plan for a release that includes the fix. |
No worries, a new version can be released if/when the CVE is added |
JSON parsing should detect embedded `\0` values
See: stleary/JSON-java#758 stleary/JSON-java#759 Port pull #759 from stleary/JSON-java to help address OOM errors described in https://www.cve.org/CVERecord?id=CVE-2023-5072 To support the JSONTokener.end() function this relies on, port over the 'eof' flag & set in all locations it's used in the latest JSON-java. Use the String next(int n) implementation from more recent java versions so we can properly check end() while reading a group of characters. Test by: - importing into alpha locally & running all tests that depend on //thirdparty:json - verifying that Snyk's proof-of-concept does not cause OOMs: https://security.snyk.io/vuln/SNYK-JAVA-ORGJSON-5962464
A better solution might be to use -1 instead 0 to represent EOF everywhere, which of course means changing
char
variables toint
. The solution here is enough to solve the immediate problem, though.Fixes #758.