Hacker News Reader

Comment by xg15 | Hacker News Reader

I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided?

Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual classes. If only one class is not available or has breaking changes, there is no (built-in) way to access anything inside the blob.

This is particularly fun if you want to refactor things. Suddenly package names, class names and names of private fields (!) are part of your public interface.

So if we could drop reflection/unsafe-based serialization and instead just got a simple parser/writer for java's binary object graph format, I'd be very happy.

View on HN

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

> Code is not data

Lisp would, of course, disagree. :-)

(import (ice-9 match))

(define data '(display code))

(define code (let ((pe primitive-eval)) (match data ((fun arg ...) (lambda () (apply (pe fun) arg))))))

(code)

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

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

[1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

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

A parable for that viewpoint: https://en.wikipedia.org/wiki/BLIT_(short_story)

> There's no such thing as "data".

In the common vernacular,

data = non-Turning complete commands

code = Turning complete commands

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

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.

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

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

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

> 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

In fact the Java Serialization Stream format (contrary to most other serialization formats) is designed such that it has well-defined grammar and you can in theory build parser that creates parse trees given only the definitions of classes involved without running any code from these classes. (ie. the parts that depend on behavior of writeObject()/readObject() are delimited inside the stream and you only need to know whether class implements such methods)

Many other language-specific serialization mechanisms just write arbitrary binary data into stream which can then only be parsed by ad-hoc recursive descent parser implemented by equivalent of java's readObject().

Reply on news.ycombinator.com