Issue sonatype-2022-6438 (fixed via #827)

[chrisgleissner]

Hi,

We are using jackson-core:2.13.4. A few hours ago, we started getting alerts that this version had the following security vulnerability and that even the latest available version 2.14.1 was affected. Thus, no known remediation path exists.

Are you aware of the issue and when do you plan to release a fix? Also, is there anything we can do in the mean-time to mitigate the issue?

Thanks
Christian

Issue sonatype-2022-6438:

"The jackson-core package is vulnerable to a Denial of Service (DoS) attack. The methods in the classes listed below fail to restrict input size when performing numeric type conversions. A remote attacker can exploit this vulnerability by causing the application to deserialize data containing certain numeric types with large values. Deserializing many of the aforementioned objects may cause the application to exhaust all available resources, resulting in a DoS condition.

Vulnerable File(s) and Function(s):

com/fasterxml/jackson/core/base/ParserBase.class

_parseSlowInt()
convertNumberToBigDecimal()
com/fasterxml/jackson/core/base/ParserMinimalBase.class

getValueAsDouble()
com/fasterxml/jackson/core/util/TextBuffer.class

contentsAsDecimal()
contentsAsDouble()
contentsAsFloat()
Detection
The application is vulnerable by using this component if it does not restrict user-supplied numeric input values prior to deserialization.

Recommendation
There is no non-vulnerable upgrade path for this component/package. We recommend investigating alternative components or a potential mitigating control.

Version Affected
[2.0.0-RC1,2.14.1]"

[cowtowncoder]

Very nice of whoever reported this to not bother contacting the project first. I have not seen a PoC of potential attack either so as far as I know this is unproven so seems wrong to have been published.

There is work in 2.15 to resolve these concerns but not for 2.14 or earlier; no backporting possible as configuration and plumbing requires significant changes, testing etc.

Fuck I hate this security theater, rogue researchers.

/cc @pjfanning

[cowtowncoder]

Also, belongs to jackson-core as that's where relevant handling would be, will transfer.

[cowtowncoder]

@chrisgleissner Aside from everything else, it is nonsense to include lower-level methods without considering actual code path: strongly-typed data (POJOs) would not necessarily refer to types (BigDecimal, possibly BigInteger) that allow targeting; and even if they do attacker would need to tailor it to known target.

I suppose CVE would refer to use with "untyped" values (readValue(Object.class)) or possibly tree mode (readTree(...)) but without more details it's hard to say.

And once again this is a good example of NON-responsible disclosure. Shame on whoever published it.

[pjfanning]

Someone probably saw the recent commits and decided to glory hunt. Shame on mitre for accepting this.

[cowtowncoder]

Yes, was thinking the same.

I think this might move up timeline for 2.15. Not by huge amount (there's holiday season now etc) but may result in enough pressure for "mini-minor version".

I really need to get started on investigating property introspection rewrite. Even if incomplete, but get something started for 2.15.

[pjfanning]

Anyone who gets this security warning should check if their application handles inputs from untrusted sources. If not, then you are safe to ignore this.
If you do allow untrusted inputs in your application, then there are many ways for malicious users to cause excessive resource use in your app. You should be looking at applying network traffic rules to check for issues before trying to parse the inputs. Your application should be built to recover from failures.

[chrisgleissner]

Thanks @cowtowncoder and @pjfanning , that is good reasoning. For Intranet applications with authenticated users, such DoS-type security issues are much less relevant. It indeed appears as though a public pull request mentioning possible security impacts (#827, slow processing times) is sufficient to create a CVE. Thanks a lot for working on this, can't wait for 2.15 to come out.

[OrangeDog]

@pjfanning Mitre haven't accepted this. It doesn't have a CVE.

[chrisgleissner]

@OrangeDog As you correctly point out (thanks), it is not a Mitre CVE but rather a Sonatype CVSS issue, see https://help.sonatype.com/iqserver/product-information/sonatype-vulnerability-data for their rating system. I changed the title accordingly and replaced 'CVE' with 'Issue'.

[cowtowncoder]

Based on some off-ticket discussion it sounds like this report sort of escaped to public sphere.
But it is also based on an older advisory so I wonder whether it might be addressed to some degree by work @pjfanning added in 2.14 already (wrt more efficient handling of BigDecimal and BigInteger -- including lazy construction which may avoid some problems too).

[deepblueli]

Based on some off-ticket discussion it sounds like this report sort of escaped to public sphere. But it is also based on an older advisory so I wonder whether it might be addressed to some degree by work @pjfanning added in 2.14 already (wrt more efficient handling of BigDecimal and BigInteger -- including lazy construction which may avoid some problems too).

It would great if that's possible as this is picked up as part of the security scanner in my company. Would save us a lot of paperworks if this can be done in 2.14 without waiting for 2.15.

[cowtowncoder]

Yes. I am not quite sure how to go about this tho.

[jensborrmann]

Not really daring to ask... Do you consider backports to older branches (2.12, 2.13)?