Upgrade to Jackson 2.8.11.20180217

[wilkinsona]

No description provided.

[wilkinsona]

This is causing some problems with Spring Security. Let's revert for now, but revisit the upgrade before 1.5.10 is released.

[wilkinsona]

There was rumour of a Jackson 2.8.11.1 that addressed the problems @rwinch encountered but it has yet to appear. Rob's going to review the situation with Security. The chances are that we'll need to defer this to 1.5.11 once he's had a chance to figure out how to work around the breaking changes.

[wilkinsona]

The current plan is to upgrade Boot in 1.5.11 and consume Spring Security 4.2.5 that also upgrades at the same time.

[vdotjansen]

I am happy to see this is planned as our (owasp) dependency checker warns us about using jackson 2.8.10, because it contains a vulnerability.
https://nvd.nist.gov/vuln/detail/CVE-2017-17485

[wilkinsona]

There’s some interesting background on the Jackson vulnerability here. The TL;DR is that you will not be vulnerable unless your app does something out of the ordinary. Boot itself does not.

[matan504]

Happy to see that there is a live discussion about this and that it is being addressed :)

[ckotzbauer]

Are there also plans to upgrade to 2.9.4+ before 2.0.0 goes final?

[rwinch]

@code-chris Spring Boot 2.0 updated to Jackson 2.9.4 in #11830 The changes are present in the current SNAPSHOTs.

[ckotzbauer]

great. Thanks @rwinch

[Konstantinos-Mavridis]

Jackson 2.8.11 also contains a vulnerability (https://nvd.nist.gov/vuln/detail/CVE-2018-5968). It's better to upgrade straight to the micro-patch 2.8.11.1 which addresses it via issue FasterXML/jackson-databind#1899 (https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8)

[wilkinsona]

Unfortunately we can't (easily) do that until Jackson's bom has been updated. I've opened FasterXML/jackson-bom#11.

[wilkinsona]

It's also worth noting that 2.8.11 isn't vulnerable by default. You have to be using Jackson in a particular way to be affected. Spring Boot itself does not do so. This blog post by @cowtowncoder is well worth reading if you haven't already done so.

[matan504]

wilkinsona, you are probably right, but the sad truth is that this sort of answer is not acceptable by the organizations that utilize our products and self-scan them for vulnerabilities. They require such versions to be removed\changed in their entirety.

[cowtowncoder]

@matan504 Perhaps it would be worth pointing out this fundamental problemn wrt naivistic scanners to organizations, for longer term improvement. There needs to be a way to indicate potential problems that require specific configuration to enable.