Thanks dropping a line Ian. I dug into this a little to understand it better, would be happy for any corrections.
It seems the prerequisite for an attack like this is to have a server that deserializes objects from an untrusted source. It should be obvious that this is a bad idea. The attack boils down to crafting a serialized object that, when deserialized, can run arbitrary code. The serialized class being constructed in the attack is clojure.inspector.proxy$javax.swing.table.AbstractTableModel$ff19274a. The Clojure inspector is a Swing app that ships inside the Clojure jar that can be used from the repl to inspect Clojure data structures. AbstractTableModel implements Serializable. The class in question is a proxied subclass of AbstractTableModel (which is thus also Serializable). Clojure proxies contain a field (__clojureFnMap) that is a map of method names to proxy methods. Clojure AOT compiles the clojure.inspector code and includes this proxied, serializable class inside the clojure jar. The attack constructs an instance of this proxy class and adds a "hashCode" proxy method to the proxy's table. The method is a Clojure function that can run arbitrary code. This instance is then put inside a HashMap and the whole thing is serialized. On deserialization, the HashMap will invoke hashCode() on the proxy object and cause the execution of the arbitrary code. I have looked at all uses of proxy in the Clojure code base, and as far as I can tell, this is the only case of a proxy of a Serializable class. A quick and effective way to address this particular case is to stop AOT compiling the clojure.inspector namespace. This removes the serializable class from the Clojure jar. Users have no impact other than making the Clojure inspector (which almost no one uses) slightly longer to start. So this is an easy fix with little impact on users. I have filed an issue at https://dev.clojure.org/jira/browse/CLJ-2204 with a patch modifying the build for this purpose for the next Clojure release. We may also consider releasing Clojure 1.8.1 with this change. Stepping back, it may also be worth considering ways to protect proxies in general, either by detecting and forbidding the proxying of a Serializable/Externalizable class without further steps or by reworking how proxies are implemented in the first place. That's likely to be a bigger change requiring a lot more analysis. I've logged a placeholder issue for this at https://dev.clojure.org/jira/browse/CLJ-2205. Thanks, Alex On Tuesday, July 11, 2017 at 11:37:30 PM UTC-5, Ian Haken wrote: > > Dear Clojure community, > > First off, apologies for directing this at the general clojure mailing > list. I was looking for a better destination, but I couldn't find any > obvious person or private mailing list to direct this to; hopefully from > here this can get in front of anyone who may be interested. > > I recently identified a means to exploit an application performing unsafe > deserialization by utilizing a "gadget chain" contained entirely in Clojure > classes. What this means is that any application which is deserializing > untrusted data and has Clojure on the classpath (whether or not it is > actually using Clojure) is subject to a remote code execution exploit. Some > more information on this form of vulnerability is available on the OWASP > wiki <https://www.owasp.org/index.php/Deserialization_of_untrusted_data>, > which also has a number of useful links for deeper discussion. > > Details of the specific gadget chain I found can be seen here > <https://github.com/frohoff/ysoserial/pull/68/files>. > > This does not represent a "security vulnerability" in Clojure, and I do > not necessarily believe that any action needs to be taken. If an > application is subject to exploit via this gadget chain, the vulnerability > is with application deserializing untrusted data. However, when > deserialization vulnerabilities became a hot topic a couple of years ago > with the discovery of a gadget chain in apache-commons > <https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread>, > > that project received a lot of attention and some made the argument that > the projects which support exploitable gadget chains should apply some form > of mitigation. For this reason, I wanted to give maintainers of this > project a heads-up in case there was any particular action you want to take. > > If you have any questions or if there's anything I can clarify, please > don't hesitate to reach out to me. > Ian Haken > Twitter: @ianhaken > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
