91–100 of 157 posts
Earlier quoted context omitted.
Blushing because this is the first I've heard of it - I owe you one :)
Where have you been hiding.
(Everything that tends to come up on HB, anyway)
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.
(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.)
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.
Earlier quoted context omitted.
> 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…
The security hole is in the design of java serialization. Any class marked serializable (in your code, your included libraries, or the JVM itself) is a potential security vulnerability as soon as you use this feature. Mark estimated that over half of JRE/JDK vulnerabilities have been due to Serialization. Recent releases added an opt-in feature to filter which classes are allowed to be deserialized, but there's still…
This is the big one: as soon as you deserialize incoming data, any library on the classpath becomes a potential source of remote-callable snippets. And when a vulnerability resides in a library, exploits will tend to be compatible across applications, which makes them far more likely to actually hit you than any custom weaknesses.
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.)
Read through it, but i wont blame language creators. Its a lot easier to point out that something is broken than to build something better.
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.
Java serialization has not many ways around it, you have to trust the sources.
XML, JSON, ... used naively with reflection (e.g. new XStream().fromXML(...)) exposes the exact same issues. Custom homemade parsers are also very likely somehow vulnerable.
The deserialization attack is a way to make the deserializer exploits vulnerable classes that exist in your classpath. It's not generating or executing malicious code by itself.
The standard classes should be ok, or at least fixed quickly.
Things like commons-collection will likely never be fixed. It might be considered as a feature from some point of view.
Check this out: https://github.com/frohoff/ysoserial
My 2 cents: - Secure your sources - Know you format, do not rely on reflection to parse text or binary data - Watch out with your classpath, but you can never know what new vulnerability will pop next weeks
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.
Sanitizing the input yourself means not using it. You can't sanitize it.
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…