Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle plans to dump risky Java serialization

infoworld.com

Post reply on HN
Print view View original

151–157 of 157 posts

Re: Oracle plans to dump risky Java serialization

#151

Post by Spivak »

AsyncAwait wrote: post #116
dnomad wrote: post #115

Earlier quoted context omitted.

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…

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

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

Re: Oracle plans to dump risky Java serialization

#152

Post by filereaper »

kitd wrote: post #139
dnomad wrote: post #115

Earlier quoted context omitted.

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…

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.

Re: Oracle plans to dump risky Java serialization

#153

Post by wepple »

gaius wrote: post #146
wepple wrote: post #130

Earlier quoted context omitted.

> Leave anything on an unprotected port taking unsanitised input and it’s vulnerable no matter what it is written in I don’t think you’re comparing apples with apples. Even in a default configuration, the majority of services that show up on a network don’t give you instant code exec. Maybe tomcat servers with default passwords, and a few other things. But (de)serialization isn’t securable at all. You can’t add auth,…

There is absolutely nothing which has that level of vulnerability and lack of security on a modern network. OK, let's say I overwrite part of your system with something evil, knowing that your app will Class.forName() it. Is that a problem with the ClassLoader or is the problem that your perimeter is already compromised anyway?

I don’t think it matters, at all.

Java has serialization, and everyone uses it, and it’s a security nightmare.

As uncomfortable as it may feel to me, I kinda agree with Oracles approach here: kill serialization, make things more secure. If they have to change core language/libraries, so be it.

You were trying to say that anything left on a network socket will be compromised, and that’s simply not true. Most software is pretty solid. Anything in C will have more than it’s fair share of upcoming patches, but unlike Java serialization, you can’t fix a single lib to fix 99% of bugs.. or we would’ve surely done that.

Re: Oracle plans to dump risky Java serialization

#154

Post by hedora »

marcodave wrote: post #120
dnomad wrote: post #115

Earlier quoted context omitted.

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…

> 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 mali…

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.

Re: Oracle plans to dump risky Java serialization

#155

Post by paulddraper »

resource0x wrote: post #119
dnomad wrote: post #115

Earlier quoted context omitted.

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…

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

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

In the common vernacular,

data = non-Turning complete commands

code = Turning complete commands

Re: Oracle plans to dump risky Java serialization

#156

Post by MichaelMoser123 »

parasubvert wrote: post #121
MichaelMoser123 wrote: post #75

Earlier quoted context omitted.

That would also kill RMI (at least JRMP), and that too would be a good thing, RMI doesn't even pass through a router (unless you do RMI-IIOP - and that is very different from regular RMI - JRMP) For java backwards compatibility used to be very important, so this is big news for the platform. I think this remoting the bytecode with serialisation madness was once upon a time very important part of RMI/serialisation - b…

If you mean that JRMP leaks internal IP addresses in the protocol itself for callbacks and thus can't be NATted, that can be fixed with a couple properties to force the use of outer-IP DNS: java.rmi.server.hostname=myhostname.com java.rmi.server.useLocalHostname=true You also can tunnel JRMP through HTTP - there was a CGI script called java-rmi dating back to the late 1990's that I think was still distributed through…

if i remember correctly then you still you need to open a port in the router so that the server can call back the client - now good luck with persuading anybody to do this kind of insanity.

Re: Oracle plans to dump risky Java serialization

#157

Post by bonzini »

dionian wrote: post #58
bonzini wrote: post #16

Earlier quoted context omitted.

Why the heck are those classes marked as `implements Serializable`?...

It is a marker interface. You are supposed to consciously opt-in.

Exactly, so I am not sure why wrappers to native pointers are Serializable.
Post reply on HN