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) > - 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
