Bug 1775193 (CVE-2019-17570) - CVE-2019-17570 xmlrpc: Deserialization of server-side exception from faultCause in XMLRPC error response
Summary: CVE-2019-17570 xmlrpc: Deserialization of server-side exception from faultCau...
Alias: CVE-2019-17570
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
: 1775192 (view as bug list)
Depends On: 1791766 1793702 1793703
Blocks: 1775263
TreeView+ depends on / blocked
Reported: 2019-11-21 14:37 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-02-16 21:00 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was discovered where the XMLRPC client implementation in Apache XMLRPC, performed deserialization of the server-side exception serialized in the faultCause attribute of XMLRPC error response messages. A malicious or compromised XMLRPC server could possibly use this flaw to execute arbitrary code with the privileges of an application using the Apache XMLRPC client library.
Clone Of:
Last Closed: 2020-01-30 20:09:32 UTC

Attachments (Terms of Use)
Proposed patch (1.47 KB, patch)
2019-12-13 10:33 UTC, Tomas Hoger
mizdebsk: review+
Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:0310 0 None None None 2020-01-30 19:27:39 UTC
Red Hat Product Errata RHSA-2020:0983 0 None None None 2020-03-26 15:49:01 UTC

Description Guilherme de Almeida Suckevicz 2019-11-21 14:37:00 UTC
Guillaume Teissier reported a flaw in Apache XMLRPC:

Java untrusted deserialization in faultCause when processing an XMLRPC response. XMLRPC clients are thus targeted by this vulnerability, and rogue XMLRPC servers may gain arbitrary code execution on the XMLRPC client.

The vulnerability lays in the org.apache.xmlrpc.parser.XmlRpcResponseParser:addResult(Object) method.

This vulnerability is different from CVE-2016-5003, which uses ex:serializable type to perform deserialization. This new vulnerability only affects XMLRPC clients, which will receive response, possible faults. It is exploitable in default configuration.

Comment 1 Guilherme de Almeida Suckevicz 2019-11-21 14:37:17 UTC

Name: Guillaume Teissier (Orange)

Comment 2 Guilherme de Almeida Suckevicz 2019-11-21 15:55:52 UTC
*** Bug 1775192 has been marked as a duplicate of this bug. ***

Comment 5 Tomas Hoger 2019-12-11 21:59:32 UTC
The support for faultCause handling was added in xmlrpc 3.1 via the following commit:


Older versions, such as those included in Red Hat Enterprise Linux 5 and 6, do not contain the relevant code and hence are not affected.

Comment 6 Tomas Hoger 2019-12-13 09:44:12 UTC
As noted in the previous comment, Apache XMLRPC version 3.1 added support for passing server-side Java exception to client by serializing it and sending it via faultCause attribute of the XMLRPC response message.  The use of this feature is supposed to be controlled via the enabledForExceptions property, which is documented as quoted below.

For server:

If the server catches an exception, and this
property is set, then the server will convert
the exception into a byte array (by using an
ObjectOutputStream) and return the exception to
the client. Note, that this may have privacy
or even security implications, because Exceptions
may contain arbitrary Java objects, which you
possibly do not want to be sent to the client.


For client:

Whether the client should request, that the
server returns exceptions as serializable objects.
If the server does, then the client will
deserialize such exceptions and throw them, as
if they had been cause within the clients code.


The property is set or read via setEnabledForExceptions() and isEnabledForExceptions() methods of XmlRpcHttpRequestConfigImpl (for client) and XmlRpcServerConfigImpl (for server) classes:


The server side works as documented, except of also needing enabledForExtensions property to be set as well.  An exception thrown is serialized using the standard Java serialization framework and included in the response message as faultCause.

The client side does not work as documented.  Client does not indicate to server in any way that it wants serialized exceptions, server decides whether to send them only based on its own configuration.  Client deserializes server-provided serialized exception whenever it finds faultCause included in the error response.  A possible fix for this issue is to ignore faultCause unless enabledForExceptions property is set.

Comment 7 Tomas Hoger 2019-12-13 10:33:23 UTC
Created attachment 1644752 [details]
Proposed patch

This implements the fix as proposed in the previously commit - it skips processing of faultCause when enabledForExceptions is not set.  This disables deserialization by default, while still allowing it when client explicitly requests so.

This change can possibly break clients that expect to get server-side exception, but are not setting enabledForExceptions.  Those would have to be fixed to set the property.

Comment 9 Tomas Hoger 2019-12-13 13:02:31 UTC

There is no known mitigation other than restricting applications using the Apache XMLRPC client library from sending requests to untrusted XMLRPC servers.

Comment 12 Mark J. Cox 2019-12-17 11:32:34 UTC
Please use CVE-2019-17570 for this issue (this CVE is from ASF CNA pool)

Comment 13 Doran Moppert 2019-12-19 00:23:50 UTC

Red Hat Enterprise Linux 7 provides vulnerable version of xmlrpc via the Optional repository.  As the Optional repository is not supported, this issue is not planned to be addressed there.

Red Hat Virtualization Manager uses xmlrpc only for internal communication with the scheduler.  Since this is a component of the Manager itself, it is not subject to attacker influence and does not represent an attack surface.

Comment 14 Siddharth Sharma 2019-12-23 07:18:05 UTC
xmlrpc version shipped with Red Hat Gluster Storage 3 as part of Red Hat Gluster Storage Console is affected. Red Hat Gluster Storage Console is not supported as of Red Hat Gluster Storage 3.5 release, this issue is not planned to be addressed in Red Hat Gluster Storage 3.

For further information:

Red Hat Gluster Storage Console

Red Hat Gluster Storage Console is not supported for use with Red Hat Gluster Storage 3.5. Red Hat Gluster Storage Web Administration is now the recommended monitoring tool for Red Hat Storage Gluster clusters.

Comment 19 msiddiqu 2020-01-16 12:46:00 UTC
Public Via https://seclists.org/oss-sec/2020/q1/10

Lifting embargo.

Comment 20 msiddiqu 2020-01-16 12:46:37 UTC
Created xmlrpc tracking bugs for this issue:

Affects: fedora-all [bug 1791766]

Comment 23 Mikolaj Izdebski 2020-01-24 11:19:43 UTC
Comment on attachment 1644752 [details]
Proposed patch

Patch looks good to me. It applies to sources of version 3.1.3.
Code looks sane - cast of "cfg" property to XmlRpcStreamRequestConfig is fine as the property is always of type.
"isEnabledForExceptions" configuration property is false by default, clients that wish to receive deserialized faultCause from servers need to set it to true.

Comment 24 errata-xmlrpc 2020-01-30 19:27:38 UTC
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS

Via RHSA-2020:0310 https://access.redhat.com/errata/RHSA-2020:0310

Comment 25 Product Security DevOps Team 2020-01-30 20:09:32 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 26 errata-xmlrpc 2020-03-26 15:48:56 UTC
This issue has been addressed in the following products:

  Red Hat Fuse 7.6.0

Via RHSA-2020:0983 https://access.redhat.com/errata/RHSA-2020:0983

Note You need to log in before you can comment on or make changes to this bug.