Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response

[Markus Koschany]

Hi Salvatore,

Am 17.01.20 um 06:31 schrieb Salvatore Bonaccorso:
[...]
> The patch proposed by Red Hat looks straightforward (with my limited
> understanding though), but might have as well potential for regression
> reports, as it is disabling deserialization by default, i.e. only uses
> it if isEnabledForExceptions is set.
> 
> So I'm wary yet on what to do for stable (and older releases and have
> not done any marking yet in the security tracker.
> 
> Opinions on that?

I have just filed

https://bugs.debian.org/949188

and asked the maintainer of starjava-topcat to remove the
build-dependency on libxmlrpc3-client-java. As it turned out it is not
even required to build the package.

As I know the patch only disables the feature to convert an exception
into a byte array but not deserialization as a whole. The problem is
that the client cannot control if potential exceptions should be
serialized and that opens a potential attack surface if someone is able
to control those serialized exceptions.

In my opinion the severity for Debian is low and besides starjava-topcat
there is only eclipse-mylyn in Jessie that depends on the library. I
don't see a potential regression in these packages but rather in the
rare case when someone uses the library in a custom project. I believe a
security announcement that explains the vulnerability and what property
needs to be set in order to restore the old behavior should be
sufficient. The version is identical in all distributions, so I think I
can just prepare an update for Jessie/Stretch/Buster and we are done
with it.

Regards,

Markus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20200118/bf2a7452/attachment.sig>