[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: remaining CVEs on libspring-java



Hello all,

I would like some input from the group on how to handle the remaining
CVEs (all of which have been tagged no-dsa) on libspring-java:

Are are the CVEs which remain open in the jessie version:

CVE-2018-1257
CVE-2018-1199
CVE-2018-11040
CVE-2018-11039
CVE-2016-9878
CVE-2016-5007
CVE-2015-5211
CVE-2015-3192
CVE-2014-3625
CVE-2014-3578

I have integrated patches for CVE-2014-3578, CVE-2014-3625,
CVE-2015-3192, CVE-2015-5211, and CVE-2016-9878 (all of which are fixed
in stretch).  CVE-2015-5211 was especially complex because of the very
large changes between the 3.0 and 3.2 releases of Spring.  I elected to
not attempt to backport the patch for CVE-2016-5007 because the "fix"
for that CVE was the introduction of a new API.  That seemed not worth
the effort, given that there are documented mitigations.

That leaves CVE-2018-11039, CVE-2018-11040, CVE-2018-1199, and
CVE-2018-1257.  Of those, CVE-2018-11039, CVE-2018-11040, and
CVE-2018-1199 are also tagged no-dsa on stretch.  CVE-2018-1257 is still
vulnerable in stretch.  It does not seem to provide a clear benefit to
implement fixes for these CVEs if they are to remain unfixed in stretch.

To fix those last few could potentially place users in a position where
a jessie systems has these issues fixed, then an upgrade to stretch
subsequently exposes them.  For that reason, I am hesitant to proceed
with fixing them.

Does that seem like a sensible position?  If not, what might be some
reasons to go ahead with the additional fixes?

Regards,

-Roberto

-- 
Roberto C. Sánchez


Reply to: