Java Deserialization vulnerability in GWT-RPC

[Thomas Broyer]

Apparently, GWT-RPC is vulnerable if you use "enhanced" classes: https://groups.google.com/d/msg/google-web-toolkit/j36D9-11JF4/OZwNQgvSAgAJ

Should we add a flag to GWT 2.8 disabling the special treatment of "enhanced classes" in GWT-RPC, generating serialization policies without @ClientFields at all? (this would possibly break applications, but at least you can be sure your application is safe)

[Jens]

I think a flag to disable the enhanced classes feature isn't worth it. Apps that need that feature will stop working so they won't use that flag. Apps that do not use this feature are not vulnerable unless the attacker can also control the content of the rpc policy file somehow.

I would output a compile error if rpc.enhancedClasses is not empty and/or JPA/JDO annotated classes are detected for RPC serialization. That makes sure everyone is aware of that security issue.

Then we would provide a flag to disable that compile error which means people must explicitly confirm that they understand that their app will be attackable through internet if they have the required classes on class path on the server. I think current exploits are all based on apache commons-collections but maybe additional libraries have already been discovered to make that deserialization exploit possible.

So I think that issue is important enough to make GWT compiles of possibly vulnerable apps stop working unless the user has set a flag to make it compile again.

-- J.

[Thomas Broyer]

On Saturday, November 21, 2015 at 3:36:02 PM UTC+1, Jens wrote:

I think a flag to disable the enhanced classes feature isn't worth it. Apps that need that feature will stop working so they won't use that flag. Apps that do not use this feature are not vulnerable unless the attacker can also control the content of the rpc policy file somehow.

I would output a compile error if rpc.enhancedClasses is not empty and/or JPA/JDO annotated classes are detected for RPC serialization. That makes sure everyone is aware of that security issue.

Then we would provide a flag to disable that compile error which means people must explicitly confirm that they understand that their app will be attackable through internet if they have the required classes on class path on the server. I think current exploits are all based on apache commons-collections but maybe additional libraries have already been discovered to make that deserialization exploit possible.

AIUI this actually has nothing to do with Apache Commons, but about any case of deserialization of untrusted data: https://www.owasp.org/index.php/Deserialization_of_untrusted_data

 

So I think that issue is important enough to make GWT compiles of possibly vulnerable apps stop working unless the user has set a flag to make it compile again.

Yup, that's what I actually meant: turn off by default, add a flag to turn back on. Ideally you'd have one flag at compile-time and one at runtime to be extra sure the offending code is never called.

There's a potential for truly fixing it though, but probably not ready in time for GWT 2.8: as java serialization is only used for roundtripping, seen as opaque on the client, the server could "sign" the payload (possibly just a HMAC) and verify the signature before deserializing it. That would require some hooks to configure the signing key, to allow sharing it between servers in a farm and/or surviving server restarts.

I'm not going to do that patch though (possibly not even the flag, let's gather some feedback first and see if anyone who actively uses GWT-RPC –I don't– volunteers to do the patch).

[Jens]

AIUI this actually has nothing to do with Apache Commons, but about any case of deserialization of untrusted data: https://www.owasp.org/index.php/Deserialization_of_untrusted_data

Yes deserialization from untrusted sources is a general issue. It just got hyped recently because apache commons-collections has some classes which allow remote code execution via deserialization and that library is literally used everywhere. 

As you already mentioned, GWT should have signed that opaque value and then verify it before deserialization.

-- J.