Re: Propose to ignore libxstream-java CVEs
On Thu, Sep 23, 2021 at 05:03:46PM +0200, Markus Koschany wrote:
>
> You are right that all applications will break which rely on the
> deserialization feature of xstream and were not using a whitelist before.
> Everything else that just writes a POJO to XML should be unaffected. In general
> we won't be able to support every custom user application that links to a
> system library but there is a simple workaround for this problem because you
> can override the permissions and even return back to a blacklist.
>
> So that leaves us with all the dependencies of libxstream-java in Debian. I
> don't see any major regressions by this switch but indeed deserialization
> without properly initializing xstream will no longer work. libjsap-java has an
> optional feature to read configuration parameters from an xml file (jsap files)
> but it still works in normal mode. It should be possible to override JSAPConfig
> but I will file a bug report anyway because this version is from 2006 and it
> does not look like it is maintained upstream.
>
> Quote from upstream:
>
> "The key message for application developers is that deserializing arbitrary
> user-supplied content is a dangerous proposition in all cases."
>
> "A blacklist for special classes only creates therefore a scenario for a false
> security, because no-one can assure, that no other vulnerability is found"
>
> I agree with him and I believe it is better to use the whitelist instead of
> relying on the blacklist. The alternative is to continue with the blacklist
> until bullseye is EOL.
>
I am also in agreement with upstream on this. There is merit in the
principle underlying Debian stable releases of not changing interfaces,
behaviors, etc. However, this seems like one of those cases where as
the world has changed, a condition/approach which might have once been
considered "not that bad" (I won't call it "good" because the blacklist
approach has essentially never been considered a good one) or adequate,
is now in a changed environment much less suitable, to the point of
essentially being harmful.
The bullseye EOL is far enough into the future that it seems like trying
to hang on to the current approach for that long is going to become
increasingly problematic. I imagine that upstream support for security
vulnerabilities associated with the old approach will either be
significantly reduced or just not even there. It seems sensible to make
the change now, rather than later after enduring lots more pain trying
to hang on to the current approach.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: