More issues like CVE-2018-1000873

[GFriedrich]

This is a followup for #90
I've just read about CVE-2018-1000873 and found more issues like these that result in a possible DoS where used within a service.
To make it more plastic, I've decided to create a table for this (feel free to split up the ticket to jackson-core too - I didn't want to create tickets in several projects at once):

Target Type/Parsed Value	10000000e10000000	1000...000	1000...000.0
Integer	🆗	#488 / :ok:	🆗 / 🆗
Long	🆗	#488 / :ok:	🆗 / 🆗
Float/Double	🆗	#488 / :ok:	🆗 / 🆗
Number	🆗	❌ / 🆗*	🆗* / 🆗*
BigInteger	🆗	❌ / ❌	❌ / ❌
BigDecimal	🆗	❌ / ❌	❌ / ❌
Instant	#90	#488 / :ok:	❌ / ❌
Duration	#90	#488 / :ok:	❌ / 🆗

🆗 = not affected (those with * may be affected when using USE_BIG_DECIMAL_FOR_FLOATS or USE_BIG_INTEGER_FOR_INTS as deserialization feature)
#XXX = fixed via the given ticket
❌ = still vulnerable
Those columns that have two values are using different code path for native numbers (first value) or numbers that are handed over as string (second value).

So as you can see, there are still several possible attack vectors.
I'm aware that you most probably don't want to change those for Number, BigInteger and BigDecimal as this may result in reduced precision. But you need to make clear for developers at some place, that using these types may result in a possible degradation of service.
What I'm worried most about are those open issues for Instant (and those using the same deserializer) and Duration. I think those need to get fixed sooner than later.

(I don't guarantee that this list is complete nor that it is correct, as most of the value were written down after reading the code - only some of them have been checked.)

[cowtowncoder]

Thank you for listing potential vulnerabilities. I am not really sure what to do here, to be honest.
But maybe someone has concrete suggestions. I do think that actual work will need to be split, and in most cases would end up either in jackson-databind (for Number deserialization, if any), or this module for Instant, Duration.

[plokhotnyuk]

Jsoniter-scala when parsing BigDecimal checks two configurable limits which have safe defaults: 1st one is for the number of significant digits and a 2nd one for the scale.

[cowtowncoder]

Would probably be good to update wrt 2.10.0, as some of the cases have been handled.
But not quite sure how to verify/update.

[cowtowncoder]

I think this:

FasterXML/jackson-core#827

to be included in 2.15.0 will actually solve issues listed here, so closing.