Apache POI Vulnerabilities

[mandrachek]

SmartClient 10.1p has an optional dependency on Apache POI 3.13. Unfortunately there are two CVE's against this version:
CVE-2017-5644 - https://www.cvedetails.com/cve/CVE-2017-5644/
CVE-2017-12626 - https://www.cvedetails.com/cve/CVE-2017-12626/

The last 3.x version 3.17 has no CVE's against it. However, it is not API compatible with 3.13, so it won't work with SmartClient's export functionality at this time.

While both of these vulnerabilities are related to parsing/reading files, and as such SmartClient itself is not vulnerable, it makes it very difficult to write such functionality in such a way that will avoid these issues - basically we'd have to create a relocated 3.17 jar (ala https://imperceptiblethoughts.com/sh...ing-relocation) to avoid the classpath conflict.

SmartClient 12.0p however uses 3.17, so at least theoretically, you could backport the export changes to 10.1p in a later build...?

[Isomorphic]

The problem with backporting the changes is that other customers direct use of POI may also be affected.

10.1 is about 3.6 years old now, so we really wouldn't recommend any new development against it, as it is getting close to end of life. Updating to the latest is a better option.

[mandrachek]

I figured something like that would be the case. Is there a public EOL schedule I can point to?

[Isomorphic]

We are currently announcing EOL decisions via our blog (eg, see this one). Note that EOL is multi-stage: a given release will still get security fixes for a while even if it has serious issues in the latest browsers, where you wouldn't want to use it outside of a controlled environment.

Big picture, it basically never makes sense to add new features to an application on anything other than the latest release. Browser vendors are constantly breaking things, and we don't port the more complicated stuff back if it's principally cosmetic or can be worked around, because it's not worth the risk. Hence problems start to accrue in aging releases well before they are officially end-of-lifed.

[mandrachek]

8.3 was announced as being EOL on 9/21/2016, with security fixes only after 01/30/2017, and de-supported as of 3/20/2017. 8.3 was supported for about 5 years and you essentially gave 6 months notice of EOL.
Currently, you are still supporting 9.0 through the latest. 9.0 is over 6 years old, and it doesn't appear to be any closer to EOL than 10.1, which as you say, is not quite 4 years old.

I know there are a lot of new features and enhancements that make these updates totally worthwhile on their own, but some customers are more risk adverse, and take an "if it ain't broke, don't fix it" approach. Without this information it's not possible to go to management and say, for example, that 10.1 is going to be EOL this year, we need to ensure the budget includes the cost of upgrading to 12.1, and that the project plan includes time to migrate the application(s).

Just something you might want to take into account when making future lifecycle decisions.

[Isomorphic]

Again, the driving decision here isn't EOL per se, it's browser support. Long before a given product has been EOL'd, it's browser support is going to be unacceptably bad.

We work with many institutions that are risk averse, unfortunately, browser vendors move faster than such institutions would like, and we don't control this. When a browser vendor just breaks something, often the effort and risk of backporting a complex fix to an older release, where code is rather different, doesn't make sense. So older releases just worsen over time.

We have no control over this - we're already making decisions on backporting that balance risk appropriately. This is just the nature of web software, driven by the browser vendors, so plan accordingly.