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

121–130 of 157 posts

Re: Oracle plans to dump risky Java serialization

#121

Post by parasubvert »

MichaelMoser123 wrote: post #75
rad_gruchalski wrote: post #59

There are so many great alternatives available. It's a no-brainer. I applaud. [edit] so why the downvote? We have YAML, JSON, protobuf, Thrift, Avro. Yup, these serialize "contents" rather than "structure + contents" but one gets interop with other technologies for free. Every tech mentioned above is so simple to use that removing Java serialization is a no-brainer.

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 Java 8 (!), and also an RMI Servlet Handler which was a bit more robust/performant. Spring also still has the RmiServiceExporter and HttpInvokerServiceExporter.

I remember building Java applets and servers that did fixed income quotes & bond trading systems via streamed encrypted serialized Java objects circa 1999-2000. What a security nightmare, but no one knew better.

I feel old.

Re: Oracle plans to dump risky Java serialization

#122

Post by parasubvert »

fs111 wrote: post #99
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…

JMX uses RMI underneath, so that would have to be fixed first before they can remove RMI

JMX protocols are pluggable, so this likely will be doable. The main issue will be updating all the ancient servers running Java < v7.

Re: Oracle plans to dump risky Java serialization

#123

Post by jdeca568 »

If i understand correctly, the problem of Java deserialization is 1) gadgets for code execution and maybe 2) DoS. And this is bad because even if it looks secure now, a gadget could be discovered later.

The default Java serialization is one of the easiest way to serialize instance of objects but there are many other ways, and many other risky ways among them.

It seems to be always the same problem: ClassLoader access. Couldn't there be a way to let the deserializers use a specific ClassLoader?

I mean some sort of (Sandboxed)ObjectInputStream that uses a specific ClassLoader defined in the JRE config. The sandboxed contexts could be defined in something like java.security, .policy, to define what it is supposed to know and when/where it is supposed to be used.

Re: Oracle plans to dump risky Java serialization

#124

Post by simias »

chii wrote: post #29
mbfg wrote: post #19

Earlier quoted context omitted.

The problems is, any class (that's serializable) that is on the target machine's classpath, can be used as a serializable object. So if i want to screw with a server, i can create a payload with any of those classes, and send it to the server. The server will load that class when it sees it in the payload, and will execute code any code in the classes static initializer, before trying to instantiate an object. All of…

> create a payload with any of those classes, and send it to the server. But on a deeper level, if a programmer doesn't know anything about security, then this sort of hole will continue to happen even if java serialization is disabled (just a bit harder to screw up). I m not that big of a fan of making security decisions without programmer's input, since you'd assume a professional programmer should know better anyw…

Programmers should be more careful but then again footguns exist (or in this case legcannons). You shouldn't trust any 3rd party data before validation but how do you validate it if you can't even deserialize it to see what it contains? It's silly.

Re: Oracle plans to dump risky Java serialization

#125

Post by steveklabnik »

jeffdavis wrote: post #21
blattimwind wrote: post #14

Earlier quoted context omitted.

Many runtimes include object serialization capabilities, which allow serialization of essentially arbitrary object structures with little code. Unpacking that kind of structure always means that you're constructing object instances of potentially any object you can construct, which generally means you can run arbitrary code. Examples: Java Serialization, Python marshal and pickle, Ruby marshal, Perl Data::Dumper.

So the problems don't apply to, say, rust because rust doesn't run arbitrary initialization when building structures?

It's not that exactly. For more: https://www.reddit.com/r/rust/comments/8mjait/is_serializati...

Re: Oracle plans to dump risky Java serialization

#126

Post by djsumdog »

gmueckl wrote: post #71
ta5244626777 wrote: post #25

Earlier quoted context omitted.

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.

Re: Oracle plans to dump risky Java serialization

#127

Post by simonh »

imtringued wrote: post #86
willvarfar wrote: post #76

Earlier quoted context omitted.

(Here's a post describing some of the problems back in the day with Ruby's YAML and JSON: https://williamedwardscoder.tumblr.com/post/43394068341/ruby... YAML is of course a format that is designed to instantiate objects as described in the source, rather than as checked by the destination, so I wouldn't want the world to adopt YAML instead of Java serialization.)

Yaml is primarily used as hierarchical config format because JSON and XML are too verbose for a human editor.

Exactly. The people loading up a YAML library and using it that way may have no idea its a potential remote code execution vector into their application.

Re: Oracle plans to dump risky Java serialization

#128

Post by philipov »

simonh wrote: post #127
imtringued wrote: post #86

Earlier quoted context omitted.

Yaml is primarily used as hierarchical config format because JSON and XML are too verbose for a human editor.

Exactly. The people loading up a YAML library and using it that way may have no idea its a potential remote code execution vector into their application.

Luckily, for those that do know what they're doing, it's simple enough to use the yaml.safe_load function that disables support for arbitrary object instantiation.

Re: Oracle plans to dump risky Java serialization

#129

Post by philipov »

jwilk wrote: post #110
kibibu wrote: post #67

Earlier quoted context omitted.

I suggest you look at the myriad security problems caused by Ruby's handling of YAML and JSON. It's not necessarily the serialization format at fault, but rather developer assumptions.

Regarding YAML, it's not just Ruby: * Python's yaml.load() hapilly executes arbitrary code. * Some Perl YAML libraries deserialize objects by default: http://blogs.perl.org/users/tinita/2018/02/safely-load-untru...

Python's YAML libraries come with a safe_load function that disables !! commands, so it can be used without loading arbitrary objects.

Re: Oracle plans to dump risky Java serialization

#130

Post by wepple »

gaius wrote: post #93

Oracle has received many reports are received about application servers running on the network with unprotected ports taking serialization streams I’m just not seeing how this is a problem with the language. Leave anything on an unprotected port taking unsanitised input and it’s vulnerable no matter what it is written in.

> 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, you can’t WAF it, you can’t fix the underlying vulnerabilities.

There is absolutely nothing which has that level of vulnerability and lack of security on a modern network.

Post reply on HN