Re: Java Deserialization Vulnerability

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

- Gerry

On Saturday, November 21, 2015 at 7:38:42 PM UTC, Jens wrote:

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.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.