Re: libxstream-java blacklist EOL?

[Sylvain Beucler <beuc@beuc.net>]

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