(De-)serialization, quo vadis

[Moritz Bechler]

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