Java Deserialization Vulnerability

[gerry]

Is GWT RPC affected by the Java deserialization vulnerability?
If so is there a way to mitigate it?

[Thomas Broyer]

On Saturday, November 21, 2015 at 5:33:00 AM UTC+1, gerry wrote:

Is GWT RPC affected by the Java deserialization vulnerability?

Hmm, apparently, and to my surprise, under certain circumstances: yes.

 

If so is there a way to mitigate it?

First, to know whether you're impacted, grep for '@ClientFields' in your serialization policies (*.gwt.rpc files).

This will be the case (IIUC) for any class annotated with JPA's @Entity or JDO's @PersistenceCapable (IIUC only the @PersistenceCapable(detachable="true") annotated classes), or listed in the gwt.enhancedClasses configuration property (from the *.gwt.xml files)

So, the way to mitigate it is to make sure you don't run into such cases. You can possibly use the rpc.blacklist configuration property to blacklist offending classes for cases where they're unexpectedly picked up.

[Thomas Lefort]

I am not very well versed into that kind of things, but how is it possible if gwt uses a white list of classes for serialization and deserialization?

[Jens]

I am not very well versed into that kind of things, but how is it possible if gwt uses a white list of classes for serialization and deserialization?

GWT-RPC has a feature that allows shared serializable classes to have additional fields on the server than at the time GWT compilation has happened. This can happen with JPA / JDO which enhance classes on server side. 

These additional fields+values are serialized on server side using normal Java serialization, then converted to Base64 and finally will be send between server and client as opaque value. When the server receives an instance of a serializable class that is marked as enhanced (the serialization policy file will have some additional information for these classes so the server knows which classes are enhanced) it will read that opaque base64 string, convert it back to binary and deserialize it using normal Java serialization in order to be able to fill the additional fields only present on server side. 

At this step the vulnerability occurs since the server deserializes data that comes from an untrusted source, the browser, without checking if the binary data is actually the data it has send to the client. An attacker can change that data to something totally different which can lead to denial of service or remote code execution.

You can read about serializing enhanced classes in GWT documentation: http://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes

Deserializing data from untrusted sources is a general issue not just in Java but lately it got some hype because someone found a way for remote code execution if a server has Apache commons-collections library on class path. As this library is used in a lot of servers and applications chances are good that you can execute any code on these servers.

So if you use that feature of GWT-RPC and you have commons-collections on class path on server side then anyone can execute code on your server by simply replaying a modified GWT-RPC request. But even without commons-collections on class path an attacker could cause an endless loop during deserialization which can lead to denial of service (when all server threads are busy).

Further reading:

https://www.owasp.org/index.php/Deserialization_of_untrusted_data

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

The proper solution is that GWT needs to sign the serialized data and verify the data before deserialization. 

-- J.

[gerry]

Interesting, many thanks Thomas and Jens,
So looks like you're in the clear as long as you're not using enhanced classes,

- Gerry

[Thomas Broyer]

On Sunday, November 22, 2015 at 9:23:11 AM UTC+1, gerry wrote:

Interesting, many thanks Thomas and Jens,
So looks like you're in the clear as long as you're not using enhanced classes,

That's right (if I'm not mistaken; I only grepped GWT sources for ObjectInputStream)

[Jakob Jarosch]

They released a new version of commons-collections (v3.2.2) which addresses this issue. So the remote code execution vulnerability is fixed, but as Jens noted, the potential DOS attack can still be executed.
https://commons.apache.org/proper/commons-collections/release_3_2_2.html
The issue in the Apache bug tracker: https://issues.apache.org/jira/browse/COLLECTIONS-580

[Lars]

@Thomas: Thanks for this information, but I guess the correct property is rpc.enhancedClasses :-)
@Jakob: Keep in mind, that commons-collections is not the only library "under attack" ... groovy and spring shares a similar use case https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads :-( I think reading objects from outside (worst case without autentication) using ObjectInputStream is always a bad idea!

[Gerry Smith]

Yeah I'd agree with that!

On Mon, Nov 23, 2015 at 8:29 PM, Lars <lars.gem...@gmail.com> wrote:

@Thomas: Thanks for this information, but I guess the correct property is rpc.enhancedClasses :-)
@Jakob: Keep in mind, that commons-collections is not the only library "under attack" ... groovy and spring shares a similar use case https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads  :-( I think reading objects from outside (worst case without autentication) using ObjectInputStream is always a bad idea!

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/j36D9-11JF4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jakob Jarosch]

Thanks Lars for the clarification. Looks like a bad plan to fix all broken implementations using ObjectInputStream and better remove it completely in a GWT-RPC environment.

[Jens]

Thanks Lars for the clarification. Looks like a bad plan to fix all broken implementations using ObjectInputStream and better remove it completely in a GWT-RPC environment.

You can use Java serialization just fine as long as you can be sure no one has modified your serialized data and that the data has actually been produced by your app. A digital signature would solve that.

-- J.