Hi, I'm not absolutely sure this is the best place to have this discussion (pointers welcome), but it's the most appropriate I figured out so far.
In the light of the most recent code execution vulnerabilities through arbitrary object deserialization - and the follow-ups that I can guarantee you to come - I think that the Java community has to have a serious discussion about serialization and it's use. If, by any chance, someone is not familiar with these issues, <https://tersesystems.com/2015/11/08/closing-the-open-door-of-java-object-serialization/> may be the best write-up on this I've seen so far. Still, the presented workarounds are mere short term mitigations because they either break a lot of stuff (yeah, disable deserialization completely), are very hard to apply (whitelisting) or are broken by design (blacklisting). Imho, this whole mess mostly results from differing positions that are taken on the issue in general: 1. using java deserialization on any input crossing a trust boundary is a vulnerability - sometimes even extending to: we don't care that our library code makes others exploitable. 2. well, we only use that on internal traffic we define as "trusted", so we don't care. (that, I would consider a rather dangerous position, I also wouldn't want my monitoring system to take over my servers or vice versa) 3. (de)serialization should be safe This is a very explosive mixture, so at some point the community has to reach an agreement on what it should be and how we are going fix this. I think we will agree that the deserialization primitive is totally broken from a security point of view at this time, but a the same time this is used (or let's even say encouraged) by quite a few of core specifications (think RMI/JRMP, JMS, JPA - although I haven't checked whether this is actually mandated by the spec, EJB, ...) - so were in a bit of a pickle here. This reflects very badly on the whole ecosystem. So, the basic choices more or less are to either fix the primitive some way or to drop it from all those technologies that use it in an potentially unsafe way. Both ways will be painful, but I think this is very necessary or issues like these will turn up every other year. Moritz -- AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731 Persönlich haftend: Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820, Vertreten durch Joachim Keltsch
