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.
Acknowledgments: Name: Guillaume Teissier (Orange)
*** Bug 1775192 has been marked as a duplicate of this bug. ***
The support for faultCause handling was added in xmlrpc 3.1 via the following commit: http://svn.apache.org/viewvc?view=revision&revision=442177 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.
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. """ https://ws.apache.org/xmlrpc/server.html 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. """ https://ws.apache.org/xmlrpc/client.html The property is set or read via setEnabledForExceptions() and isEnabledForExceptions() methods of XmlRpcHttpRequestConfigImpl (for client) and XmlRpcServerConfigImpl (for server) classes: https://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/common/XmlRpcHttpRequestConfigImpl.html#setEnabledForExceptions%28boolean%29 https://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/XmlRpcServerConfigImpl.html#setEnabledForExceptions%28boolean%29 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.
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.
Mitigation: There is no known mitigation other than restricting applications using the Apache XMLRPC client library from sending requests to untrusted XMLRPC servers.
Please use CVE-2019-17570 for this issue (this CVE is from ASF CNA pool)
Statement: 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.
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: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/3.5_release_notes/index#support-limits-and-removals 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.
Public Via https://seclists.org/oss-sec/2020/q1/10 Lifting embargo.
Created xmlrpc tracking bugs for this issue: Affects: fedora-all [bug 1791766]
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.
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
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-17570
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