Re: libxstream-java blacklist EOL?
Hi,
On 07/06/2021 09:40, Emilio Pozuelo Monfort wrote:
On 02/06/2021 14:24, Markus Koschany wrote:
Am Mittwoch, den 02.06.2021, 12:26 +0200 schrieb Emilio Pozuelo Monfort:
I think it is time
we declare the block list unsupported, asking users to switch to the
allow
list.
Thoughts?
I believe it is sensible to switch to the whitelist by default after
we have
tested the reverse-dependencies. This is quite similar to
jackson-databind.
Ack. I added this to [de]la-needed. Indeed some testing and/or code
inspection on the rdeps will be needed.
(I'm checking the libxstream-java currently in dla-needed.txt.)
The black->white list switch is planned for the unreleased XStream
1.4.18, or possibly 1.5.0.
https://x-stream.github.io/security.html#explicit
This may require changes in the reverse dependencies that didn't happen
yet in their respective upstream versions.
I think it would be safer to wait and check how these upstream projects
handle the change, rather than branching our own solutions to this
incompatible change, and just fix CVE-2021-29505 explicitly meanwhile
(given it can trigger RCE).
What do you think?
----
Note: I also started checking the stretch reverse dependencies:
None of the rdeps seem to set a policy
(addPermission/addType*/denyPermission/denyType*).
Direct rdeps are:
groovy: not vulnerable (serialize-only)
jajuk: possibly vulnerable
jakarta-jmeter: possibly vulnerable
jodconverter: possibly vulnerable
jsap: possibly vulnerable
maven-war-plugin: possibly vulnerable
natbraille: not vulnerable (no direct use)
powermock: possibly vulnerable
tiles-autotag: possibly vulnerable
uima-as: not vulnerable (no direct use)
I don't think there are indirect uses involving more
reverse-dependencies (would have probably been the case for the Groovy
programming language, but fortunately its use of xstream is limited).
I plan to further check which ones would break with a white list.
Cheers!
Sylvain
Reply to: