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

Re: libxstream-java blacklist EOL?


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


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.

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.


Reply to: