Hacker News Reader

Comment by Hupriene | Hacker News Reader

Having used java serialization a few times for POC level work, I'll be sorry to see it go.

I wish they would just rename it something sufficiently ominous sounding that people wouldn't think about using it on untrusted data sources.

Maybe AribitraryCodeAndDataSerialization

View on HN

Might catch some cases, but just from a couple of weeks ago, by an org that supposedly puts security very high up the priority list we had this: https://news.ycombinator.com/item?id=17096022 (Signal's security hole created by using dangerouslySetInnerHTML)

Yes it was a nice/quick/dirty way to persist an object graph, I bet it's been abused richly in a lot of codebases out there, it'll be curious to see how this is handled in terms of breakage i.e. the JDK that introduces this might be the Python 2/3 showdown (if that's still a thing).

Be curious to do a Github wide grep for ObjectOutputStream or something similar and see what it's like in open source land.

This is made more exciting by the fact that Java rarely introduced big breaking changes in the past. Especially deprecated classes (java.util.Date...) never were actually removed. Starting this now is going to wreak havoc.

We're already starting to see the effects in Java 9. Our team attempted to use it on our current project and many of our dependencies broke because they were using deprecated parts of the API that were removed. We ended up having to drop back to Java 8.

Speaking of Python, pickle is `eval` soooo be a little careful with that one.

Coming from a Javascript context, would this be something roughly analogous to expecting JSON.parse and actually getting eval?

Pretty much. It's slightly less terrible than that -- the deserializer doesn't evaluate arbitrary Java expressions, but it can call no-argument constructors, run deserializer methods, and set field values (including private fields) on any loaded class that's marked Serializable.

As you can imagine, any sufficiently large codebase is likely to have a million different ways this can be leveraged to get arbitrary code execution.

> Maybe AribitraryCodeAndDataSerialization

Wait, what? Java serialization does not serialize and deserialize code. The only thing encoding behavior when serializing is class names. The receiving system needs to know those classes/be able to load them.

... unless you override Java's default serialization behavior and build a whole lot of black magic.

Apparently there are some vulnerabilities in the implementation, but they are not an inherent part of it as some people seem to think.

> unless you override Java's default serialization behavior and build a whole lot of black magic.

...but then, if the developer is writing custom deserialization code that does black magic (like, executing the equivalent of eval() on a content of a String field), any serialized format is affected, be it binary, JSON, YAML, etc

Reply on news.ycombinator.com