Hi, On Fri, Jun 18, 2021 at 06:35:11PM +0200, Sylvain Beucler wrote: > 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.
Follow-up: all would fail, since all serialize app-specific classes. The (strict) default white-list can be simulated by calling XStream.setupDefaultSecurity(xstream); This blocks all app-specific classes. Each package would need a patch with a series of: XStream.setupDefaultSecurity(xstream); xstream.allowTypes(new Class[] {AppSpecific.class, ...}); for each use of XStream, and annoyingly there are a few uses indirect cases (powermock, jajuk, jakarta) where the expected classes are not directly known. Let's revisit this when there's a released XStream with the default whitelist, and upstream reactions, as detailed above. Meanwhile, should we update buster's black list? Cheers! Sylvain