[CVE-2022-40151] Fix StackOverflowError

[basil]

This PR starts by copying clusterfuzz-testcase-minimized-XmlFuzzer-4827085820002304 from #314 into xstream/src/test/com/thoughtworks/acceptance/CVE-2022-40151.xml and adds a new test that fails with the stack trace described in #314. It then goes on to fix the problem by introducing the concept of a recursion depth limit (set to 500 by default), which prevents the StackOverflowError from occurring. The test case sets the recursion depth limit to 600 and asserts that this limit was reached in order to test that the limit can indeed be increased. With the changes to xstream/src/java/, the new test now passes.

Closes #314

[udhay-tw]

Fixing [CVE-2022-40151] will help all the libraries having transitive dependencies.
Thanks for the work around being shared in https://github.com/x-stream/xstream/security/advisories , which will help with direct dependencies
Thanks for your effort

[christophersavory]

@joehni have you seen this PR?

[joehni]

@basil: Thanks for the pull request, but unfortunately this will not fix CVE-2022-40151, it will make it just less likely.

A StackOverflowError is like an OutOfMemoryError, that can be triggered by providing a big amount of data e.g. for a byte array. Since the stack size of a thread is depending on the environment and even configurable, you might reach the limit much faster than expected.

However, I'll add this to the next release, because it provides the ability to limit the stack size for your input if you know its depth in advance. Exceeding this limit is likely an attack then.

[basil]

this will not fix CVE-2022-40151, it will make it just less likely.

Just like FasterXML/woodstox#160 / FasterXML/woodstox#159, which was apparently enough to "resolve" CVE-2022-40152 🤷‍♂️

[VipinMiglani]

May i get an update on this PR? When can we expect this vulnerability addressed? Thanks

[joehni]

May i get an update on this PR? When can we expect this vulnerability addressed? Thanks

It depends on my spare time.