Closed padolph closed 5 years ago
Yes, I can see how this could be problematic. JSON parser had a similar potential case for sub-tree copying fixed recently.
I'll have to think of a good way to handle this: simple depth counter could work, given that tags shouldn't really need to nest deeply. Or perhaps changing handling to use iteration & stack instead.
Thank you for reporting this issue.
Looked at possible solution and I think I know how to handle this as there is only one codepath (special tag handling for another use case does not use recursive calls).
Great news! Yes that was my observation too, only one code path was involved. Thanks for taking this on.
@padolph thank you for reporting it! One of those things that are obvious in hindsight, but not before :) I will get this in 2.10.1, it's the next thing for me to work on.
Ok so end result is bit messy, due to necessary nesting (BigDecimal
being sometimes encoded with BigInteger
encoded as tagged binary chunk....); may become actual problem if more tags are to be recognized. But should work for now, we'll see how things go.
It is very easy to craft CBOR tagged array data that causes a java.lang.StackOverflowError. Because the CBOR implementation of JsonParser.nextToken() recurses internally when it encounters tagged array data, there is very little the application programmer can do to protect against this exception. Suggest rethinking the recursive approach, or at least capping the max recursion depth.
For CBOR parsers that process untrusted data, this creates a serious DOS vulnerability. Most likely any CBOR parser implemented using Jackson is vulnerable to this problem.
Here is code that generates (nonsensical) CBOR data that crashes the JVM with a StackOverflowError. I am currently using jackson-dataformat-cbor-2.9.9
This program will try many values of array recursion depth until the JVM crashes. On my laptop this happens around 'level' 10000.