4 ms·

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 soun

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

crooked-v 8y ago
Coming from a Javascript context, would this be something roughly analogous to expecting JSON.parse and actually getting eval?
- teraflop 8y ago
  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.
askvictor 8y ago
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 https://news.ycombinator.com/item?id=17096022 (Signal's security hole created by using dangerouslySetInnerHTML)
ta5244626777 8y ago
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.
- sitkack 8y ago
  Speaking of Python, pickle is `eval` soooo be a little careful with that one.
- gmueckl 8y ago
  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.
  - Turbots 8y ago
    why is it going to wreak havoc? Java 8 will be supported until 2020 and Java 11 (next LTS version, due in September this year) will be supported until probably 2022. This change will come even after that. I wish they would have killed classes like java.util.Date long ago, since its one of the worst classes which is widely used in the JRE. Serialization was invented in 1997 and has no real usecase anymore.. You want loose coupling and tightly bounded contexts, not the other way around.
  - djsumdog 8y ago
    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.
quelltext 8y ago
> 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.
- quelltext 8y ago
  ... 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.
  - marcodave 8y ago
    > 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

crooked-v 8y ago

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

teraflop 8y ago
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.

askvictor 8y ago

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 https://news.ycombinator.com/item?id=17096022 (Signal's security hole created by using dangerouslySetInnerHTML)

ta5244626777 8y ago

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.

sitkack 8y ago
Speaking of Python, pickle is `eval` soooo be a little careful with that one.
gmueckl 8y ago
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.
- Turbots 8y ago
  why is it going to wreak havoc? Java 8 will be supported until 2020 and Java 11 (next LTS version, due in September this year) will be supported until probably 2022. This change will come even after that. I wish they would have killed classes like java.util.Date long ago, since its one of the worst classes which is widely used in the JRE. Serialization was invented in 1997 and has no real usecase anymore.. You want loose coupling and tightly bounded contexts, not the other way around.
- djsumdog 8y ago
  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.

quelltext 8y ago

> 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.

quelltext 8y ago
... 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.
- marcodave 8y ago
  > 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