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

141–150 of 157 posts

Re: Oracle plans to dump risky Java serialization

#141

Post by api »

dnomad wrote: post #115
xg15 wrote: post #104

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

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…

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

Re: Oracle plans to dump risky Java serialization

#142

Post by nqzero »

dnomad wrote: post #115
xg15 wrote: post #104

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

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…

> 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

Re: Oracle plans to dump risky Java serialization

#143

Post by willvarfar »

philipov wrote: post #128
simonh wrote: post #127

Earlier quoted context omitted.

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.

I believe that the safe_load function only got added because of the spate of exploits that the blog post was talking about.

Its good that its been added, although it would have been better if it'd been there from the beginning and the safe version was default and you had to invoke 'unsafe_load' if you wanted complex object instantiation, to hopefully encourage even novices to think twice before doing it with tainted input.

Re: Oracle plans to dump risky Java serialization

#144

Post by peeters »

eicnix wrote: post #114
dpark wrote: post #111

Earlier quoted context omitted.

How does that work? You describe a situation in which code that does not exist on a given node is executed on that node nonetheless.

You write a query that is wrapped inside a serializable object. The object with your code inside is serialized using Java object serialization and distributed to every node. Each node is now able to execute your query based on Java code. https://ignite.apache.org/features/computegrid.html

This isn't a native feature of Java serialization. Class implementations are not included in the serialized data.

> How do closures get shipped around?

> Every closure is an object of a particular class. When the closure is being sent it gets serialised to a binary form, send over the wire to a remote node and deserialised there. The remote node should have the closure's class in its classpath or enable peerClassLoading in order to load the class from the sender side.

https://apacheignite.readme.io/docs/faq

Re: Oracle plans to dump risky Java serialization

#145

Post by marcodave »

quelltext wrote: post #112
quelltext wrote: post #108

Earlier quoted context omitted.

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

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

> 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

Re: Oracle plans to dump risky Java serialization

#146

Post by gaius »

wepple wrote: post #130
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,…

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?

Re: Oracle plans to dump risky Java serialization

#147

Post by jwilk »

ArneBab wrote: post #134
philipov wrote: post #129

Earlier quoted context omitted.

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

And they warn quite clearly about that. Though in hindsight, having load and unsafe_load would have been safer.

> And they warn quite clearly about that.

Do they?

https://github.com/yaml/pyyaml doesn't even mention safe_load().

And this is the docstring for yaml.load():

  Parse the first YAML document in a stream
  and produce the corresponding Python object.
This doesn't sound very scary, and certainly doesn't imply possible code execution.

Re: Oracle plans to dump risky Java serialization

#148

Post by alkonaut »

mbfg wrote: post #19
jeffdavis wrote: post #12

Can someone briefly explain the problems and how general they are to other serialization interfaces?

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…

I can see how it's potentially a problem, but I still don't understand where the vulnerability occurs. The static initializers will be run before the data (which the attacker controls) is inserted into those instances. Yet the attacker has to be able to somehow "execute" code via the data he sends.

There has to be a few specific classes that are common, and that have methods that the attacker can expect will be run (such as toString conversion, comparison etc), where the attacker can control the data used.

E.g. if he knows that serializing a certain collection type containing Font objects will use some platform native code that reads the font data, he can then pass a corrupt font in and fool the deserializer into an out of bounds read. Or something like that. I vaguely remember hearing about one of these attacks and I can't find it. It would be interesting to hear about some real world attacks.

Re: Oracle plans to dump risky Java serialization

#149

Post by quickthrower2 »

iainmerrick wrote: post #91
quickthrower2 wrote: post #72

Earlier quoted context omitted.

Where have you been hiding.

I’m beginning to think there really is an xkcd for everything: https://www.xkcd.com/1053/ (Everything that tends to come up on HB, anyway)

I meant it in a friendly way, knowing that there is a tonne of shit I don't know. But ASCII can't convey that. Maybe Unicode can. Should of put a smiley.

Re: Oracle plans to dump risky Java serialization

#150

Post by paulddraper »

skocznymroczny wrote: post #84
echelon wrote: post #79

Earlier quoted context omitted.

Protos are amazing and have so many advantages over json. You'll love them!

Wouldn't they be a pain to debug, given that they are binary? I wouldn't want to use a hex editor to verify if my data serializes properly.

There is a robust though mostly undocumented text format.

I've even seen Google projects use text protos for config files.

Or to decode binary files, use the protoc tool.

Post reply on HN