Re: libxstream-java blacklist EOL?
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
Reply to: