4 ms·

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and

by dnomad 8y ago

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize how enormously dangerous it is. If you want data then define a schema and write/read your data. Serialization should really never be used and certainly not for long-lived data storage. There is one place where serialization becomes useful and that is for storing objects off-heap, IPC, and for short-term storage (ie snapshots like Android's parcelable). For these cases I'd like to see the JVM embrace not just immutable value objects but full-fledged structs that have a well-defined memory layout. You can do this today using off-heap Buffers and interfaces but language support is always good so there's a universal standard that everybody can build upon. Once that's in place there'd be no need to ever use serialization. That said I can't imagine Oracle will simply remove support object serialization. It may be kicked out of the "core" JDK and become an optional module. The classes may be deprecated. But the functionality likely isn't going anywhere in the next ten years. Even if they did remove it nobody should be using the standard object serialization anyways. If you're going to use serialization (and you shouldn't) then you should absolutely be using FST [0]. [0] https://github.com/RuedigerMoeller/fast-serialization https://github.com/RuedigerMoeller/fast-serialization

AsyncAwait 8y ago
> Code is not data Lisp would, of course, disagree. :-)
- ArneBab 8y ago
  (import (ice-9 match)) (define data '(display code)) (define code (let ((pe primitive-eval)) (match data ((fun arg ...) (lambda () (apply (pe fun) arg)))))) (code)
- Spivak 8y ago
  Lisp recognizes that the difference between code and data is the context they're interpreted in. A more accurate phrasing of "code is not data" should be, "data from untrusted sources should not be interpreted as code".
dnomad 8y ago
BTW, contrary to other comments this has nothing to do with the binary nature of serialization. The problem is that serialized "data" are programs. They're code. For some really scary stuff see the XMLDecoder [0] API which is XML-based " Java-bean serialization" but actually enables arbitrary code execution. Note that even when it's not an explicit feature serialization libraries have a tendency to become unexpectedly Turing-complete [1]. There are many, many systems out there that are vulnerable to "surprise Turing" attacks. The only real defense against this is to have well-documented schemas in place and to thoroughly validate all incoming data. Ironically all the guys churning out schema-less JSON microservices think they're okay. They're not. As they say the truth is even worse than it appears... [0] http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execut... [1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
resource0x 8y ago
There's no such thing as "data". Every piece of "data" eventually gets interpreted, thus becoming a "command" in some level of abstraction. The core of every security vulnerability is the belief that "this is just a piece of data".
- ableal 8y ago
  A parable for that viewpoint: https://en.wikipedia.org/wiki/BLIT_(short_story) https://en.wikipedia.org/wiki/BLIT_(short_story)
- paulddraper 8y ago
  > There's no such thing as "data". In the common vernacular, data = non-Turning complete commands code = Turning complete commands
marcodave 8y ago
> serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. As I recall, the default behavior of Java (de)serializer, would only write the data fields one by one in binary format. The code itself, i.e. the bytecode of the methods and the class definition itself have to be in the classpath at application startup, so how could this malign code be injected as part of the attack?
- hedora 8y ago
  In the face of an attack, the serializer framework unexpectedly invokes arbitrary existing methods/constructors on untrusted data, including malformed private object states. So, if the attacker can trick one class anywhere on the classpath into doing something bad, then they can bootstrap an attack. It is similar to “return oriented programming”, which is one way to escalate c stack overflows to arbitrary code execution.
kitd 8y ago
The IBM J9 JVM comes with a library called PackedObjects, ie objects whose memory can be off-heap too.
- filereaper 8y ago
  Project Valhalla had more community support than PackedObjects. PackedObjects was unfortunately removed from later versions of J9.
api 8y ago
> In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize how enormously dangerous it is. This sentence neatly describes one of the major ways things have changed since the 90s. Computing is now a war zone, rendering many of the elegant and beautiful distributed systems concepts discussed back then off the table. Instead we have walled gardens, closed platforms, closed systems, and closed pretty much everything. Anything open is immediately spammed and exploited to death.
nqzero 8y ago
> Objects are not data this is not true. the jvm may choose to make serialization more complicated than it needs to be, but an object is nothing more than a collection of locations in memory what's fundamentally wrong is sun/oracle's insistence on running constructors, not serialization itself

by dnomad 8y ago

AsyncAwait 8y ago

> Code is not data Lisp would, of course, disagree. :-)

ArneBab 8y ago
(import (ice-9 match)) (define data '(display code)) (define code (let ((pe primitive-eval)) (match data ((fun arg ...) (lambda () (apply (pe fun) arg)))))) (code)
Spivak 8y ago
Lisp recognizes that the difference between code and data is the context they're interpreted in. A more accurate phrasing of "code is not data" should be, "data from untrusted sources should not be interpreted as code".

dnomad 8y ago

BTW, contrary to other comments this has nothing to do with the binary nature of serialization. The problem is that serialized "data" are programs. They're code. For some really scary stuff see the XMLDecoder [0] API which is XML-based " Java-bean serialization" but actually enables arbitrary code execution. Note that even when it's not an explicit feature serialization libraries have a tendency to become unexpectedly Turing-complete [1]. There are many, many systems out there that are vulnerable to "surprise Turing" attacks. The only real defense against this is to have well-documented schemas in place and to thoroughly validate all incoming data. Ironically all the guys churning out schema-less JSON microservices think they're okay. They're not. As they say the truth is even worse than it appears... [0] http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execut... [1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

resource0x 8y ago

There's no such thing as "data". Every piece of "data" eventually gets interpreted, thus becoming a "command" in some level of abstraction. The core of every security vulnerability is the belief that "this is just a piece of data".

ableal 8y ago
A parable for that viewpoint: https://en.wikipedia.org/wiki/BLIT_(short_story) https://en.wikipedia.org/wiki/BLIT_(short_story)
paulddraper 8y ago
> There's no such thing as "data". In the common vernacular, data = non-Turning complete commands code = Turning complete commands

marcodave 8y ago

> serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. As I recall, the default behavior of Java (de)serializer, would only write the data fields one by one in binary format. The code itself, i.e. the bytecode of the methods and the class definition itself have to be in the classpath at application startup, so how could this malign code be injected as part of the attack?

hedora 8y ago
In the face of an attack, the serializer framework unexpectedly invokes arbitrary existing methods/constructors on untrusted data, including malformed private object states. So, if the attacker can trick one class anywhere on the classpath into doing something bad, then they can bootstrap an attack. It is similar to “return oriented programming”, which is one way to escalate c stack overflows to arbitrary code execution.

kitd 8y ago

The IBM J9 JVM comes with a library called PackedObjects, ie objects whose memory can be off-heap too.

filereaper 8y ago
Project Valhalla had more community support than PackedObjects. PackedObjects was unfortunately removed from later versions of J9.

api 8y ago

> In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize how enormously dangerous it is. This sentence neatly describes one of the major ways things have changed since the 90s. Computing is now a war zone, rendering many of the elegant and beautiful distributed systems concepts discussed back then off the table. Instead we have walled gardens, closed platforms, closed systems, and closed pretty much everything. Anything open is immediately spammed and exploited to death.

nqzero 8y ago

> Objects are not data this is not true. the jvm may choose to make serialization more complicated than it needs to be, but an object is nothing more than a collection of locations in memory what's fundamentally wrong is sun/oracle's insistence on running constructors, not serialization itself