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
Stack exhaustion parsing a JSON file #1136
Comments
|
Actually, this does not appear to be a parsing error, which I think is good news: |
|
This is simply running out of stack space during jv_dump_term(). I was able to make the number of recursions go up by 11,000 or so by dynamically allocating variables instead of using stack space, but at the end of the day, you can work around this (for this test case) by doing: ulimit -s 32768Of course, a much larger (deeper) json file will still make it crash. You can thus, make it happen far faster by doing: ulimit -s 256The crash does not seem to happen due to any buffer overflows or memory corruption; it's simply the kernel saying "you're out of stack space, please die". One simple way to avoid the crash itself is to do a depth-check of the tree and compare it to some value related to the stack size returned by getrlimit() and produce an error if the values are way out of whack. A more complicated solution would involve removing recursion from jv_dump_term(), which looks like it would not be a trivial fix. |
|
This issue is referenced as CVE-2016-4074. |
This addresses stedolan#1136, and mitigates a stack exhaustion when printing a very deeply nested term.
This addresses stedolan#1136, and mitigates a stack exhaustion when printing a very deeply nested term.
This addresses stedolan#1136, and mitigates a stack exhaustion when printing a very deeply nested term.
This addresses #1136, and mitigates a stack exhaustion when printing a very deeply nested term.
This addresses stedolan#1136, and mitigates a stack exhaustion when printing a very deeply nested term.
|
If I understand correctly this was fixed by 83e2cf6. Suggest closing. |
|
Good point. Closed. |
|
By all indications this problem is not solved. It still appears on the Common Vulnerabilities & Exposure (CVE) list. |
|
@taneishamitchell - how do you figure its not solved? Just tested this with the provided json above and it didn't crash.
|
|
Assuming that this IS actually fixed, it is still being flagged by some tools. Clair (and also possibly dependent scanning tools): |
|
Still flagged by AWS ECR Vulnerabilities scanner... |
|
Confirmed, still getting flagged by AWS ECR |
|
I am using this version and still getting flagged in my ECR. Is this false positive? |
|
I'll just put this here for others... Subject: Amazon ECR Update to Address False Positive Findings of CVE-2020-28928
False positive. Should be gone on June 22nd. Enjoy explaining that to your Security guys. ;-) UPDATE: Sorry I have got the wrong CVE. |
Hi,
A crash caused by stack exhaustion parsing a JSON was found. It affects, at least version 1.5 as well as the last git revision. To reproduce:
Find attached a JSON file to reproduce it here
Regards,
Gustavo.
The text was updated successfully, but these errors were encountered: