Deserialization Issues Also Affect Ruby -- Not Just Java, PHP, and .NET (zdnet.com)

An anonymous reader writes: The Ruby programming language is impacted by a similar "deserialization issue" that has affected and wreaked havoc in the Java ecosystem in 2016; an issue that later also proved to be a problem for .NET and PHP applications as well. Researchers published proof-of-concept code this week showing how to exploit serialization/deserialization operations supported by the built-in features of the Ruby programming language itself.

"Versions 2.0 to 2.5 are affected," researchers said. "There is a lot of opportunity for future work including having the technique cover Ruby versions 1.8 and 1.9 as well as covering instances where the Ruby process is invoked with the command line argument --disable-all," the elttam team added. "Alternate Ruby implementations such as JRuby and Rubinius could also be investigated."

The deserialization issues can be used for remote code execution and taking over vulnerable servers. While .NET and PHP were affected, it was Java until now that has faced the biggest issues with deserialization, earlier this year, Oracle announcing it was dropping deserialization support from the Java language's standard package.

Comments

Dropping support?!?

[Anonymous Coward]

XML was supposed to fix all this!

And we all know, XML is like violence: if it doesn't fix the problem you're not using enough of it.

Re:Dropping support?!?

[gweihir]

If XML has been designed by people that actually understand security, if _could_ have fixed the issue. But all the security-ignorant masses of developers ever want is features, features and more features. They would probably have rejected an actually secure XML.

Re: Dropping support?!?

[phantomfive]

The problem has nothing to do with XML. It is a problem with serialization. Even if you use json or yaml or whatever, there are still security issues.

That's what you get for being lazy.

[Qbertino]

Serialisation and deserialisation happens when developers get lazy and/or the original architects of the system designed a shitty appmodel. Or none at all. You see this nice and clearly in PHP CMSes such as Expression Engine or WordPress.

It goes like this:
Check out the model, see bunch of crap, think: "Oh I know, I'll just serialize my stuff and dump it into a single field." Newer stuff in WP is full of this and it doesn't help that this is tacked on to a baaad application model with some really shitty DBAL mechanisms that quickly grow to 2-digit amounts of SQL statements being executed per API call and an ERD designed on crack.

The truth of the matter is: If you don't take total control of your data every step of the way you are bound to be screwed when an exploit like this crops up. Simply serializing is the exact opposite of taking control. And taking control is basically impossible if you don't know how to design your app or its DB.

Whenever I see serialized data lying around in persistence, I know that someone further up didn't do his job.

My 2 eurocents.

Re:That's what you get for being lazy.

[gweihir]

I don't think it is laziness. I think it is plain incompetence. These people cannot really code and hence they need all these features to get anything to work at all. Of course, they also do not know how things actually work under the hood and they have zero understanding of security, nicely leading to the mess we can observe almost everywhere.

But then, if you get competent coders, you may actually have to pay them like the qualified engineers they are. "Management" cannot have that. A coder may actually earn _more_ than a manager with this! The sky would be falling!

Re:That's what you get for being lazy.

[Luthair]

I've been attempting to the write this and not sound like a jerk.... but serialization simply means translating whats in memory into a format that can be stored. Even the scenario you're complaining about isn't necessarily "bad", it sounds like they're using it as an alternative to disk storage and as long as they aren't running queries on the contents of the field that isn't a problem.

The issue that Java (and presumably Ruby, though I don't care enough about Ruby to check) is that it turned out to be possible to craft serialized objects that simply deserializing would cause code execution. In the case of Java most development had long since switched to using other formats instead of native binary serialization before the vulnerabilities were discovered but as there are a ton of legacy applications and frameworks people still had problems.

Re:That's what you get for being lazy.

[iggymanz]

nonsense

moving a program from one place to another can face identical issues.

the path is secure, or it is not secure.

serialization irrelevant.

Re:That's what you get for being lazy.

[iggymanz]

wrong

serialization of an object is very useful.

the path it moves on must be secure. if it is not secure, then you can have the same issues moving information or code by other means.

serialization not the problem if the path is compromised.

Re:That's what you get for being lazy.

[sphealey]

Most of what I have seen is (1) lack of understanding of what databases are, what they were designed to do, and what they are capable of (2) fear of using databases based on a shared cultural non-understanding stemming from 1 (3) broken workaround after broken workaround to allow the architect and developer... not to use databases.

Re:That's what you get for being lazy.

[Actually, I do RTFA]

Using serialization operations (properly to a non-binary format) makes things more resilient to changes. You can roll your own, but then again, that seems more likely to be prone to errors. NIH-syndrome is a bitch.

Re: That's what you get for being lazy.

[phantomfive]

If you think native binary serialization is the problem then you are ignorant (either that or you expressed yourself in a way I didn't understand). It doesn't matter if you use binary, or XML, or Jason or yaml, these vulnerabilities are going to be there. It's not just Java either, it's basically any language that does deserialization automatically on untrusted data. The reason is simple: untrusted data needs to be sanitized and treated as dangerous every step of the way. Sanitizing can't be done in an automated way without knowing how the data is going to be used. For example, something that is going into a database needs to be sanitized in a different way than something going into an excel form, and differently than something going onto a web page. Furthermore, you need to always treat untrusted data as untrusted, because when your application grows and it gets used I'm a context you didn't originally expect, you will need to purify it again (this is a well know excel exploit).

Re:That's what you get for being lazy.

[angel'o'sphere]

Whenever I see serialized data lying around in persistence, I know that someone further up didn't do his job.
You mean inside of a database?

There is nothing wrong with serialization. Use it when it is appropriated, don't use it if not.

My 2 eurocents.

Luckily a bit more worth than 2 US cents :D but your opinion: nope.

Re:That's what you get for being lazy.

[angel'o'sphere]

have zero understanding of security
Unless the programmer of the deserialization code did not plant an easter egg, aka a trojan, into the deserialization code: there is no security issue at all!

WTF ... what is next? An SQL select from a database is a security issue?

Re:That's what you get for being lazy.

[angel'o'sphere]

is that it turned out to be possible to craft serialized objects that simply deserializing would cause code execution.
Actually it does not. Unless the writer of the relevant classes deliberately put some special "deserialize()" methods into the classes on the server. Exploit from outside is completely impossible unless a programmer deliberately put in a back door.

Re:That's what you get for being lazy.

[TechyImmigrant]

Most of what I have seen is (1) lack of understanding of what databases are, what they were designed to do, and what they are capable of (2) fear of using databases based on a shared cultural non-understanding stemming from 1 (3) broken workaround after broken workaround to allow the architect and developer... not to use databases.

That's because databases are heavy lifting for light problems. Avoidance is rational.

Re:Deserialization

[gweihir]

Most secure coding these days still boils down to "you have to know what you are doing". I don't see that changing anytime soon. Brooks famous statement "There is no silver bullet" still applies and will continue to apply for a long, long time.

Re:It is only a problem if

[gweihir]

The problem with deserialization is that it gives tools to fools and makes them more dangerous fools as a consequence.

In the hands of an expert, it is just a feature that is nice to have. But most people writing software are not experts.

Re:Seriously?

[gweihir]

The news here is that we have _still_ not managed to assure any level of real skill in the people writing software. This cannot continue.

It boils down to

[jabberw0k]

• Data read from a file or network is only as secure as that file or network.
• There are reasons why the Unix Way abolished binary data files wherever possible in favor of plain text files; read The Art of UNIX Programming by ESRaymond.

Re:It boils down to

[Eravnrekaree]

Binary formats can be perfectly safe, it takes a competent person to write the processors for them. They are not more difficult to write than one for a text based format, so its not like text based formats are safer. They can save some CPU cycles since using length field demarcation rather than demarcation characters, you dont have to inspect every single character.

Re:It boils down to

[Cesare Ferrari]

Agreed. The simplest binary formats are very simple to store and retrieve, if you think about it, you just create a struct with non-pointer/reference types, and write your fields. Serialisation is a write of the memory to a file, deserialisation is a read. All in all, it'll be 10 lines of blindingly obvious code without any chance of programming errors, buffer overruns etc.

However, and this is a big however, it's completely inflexible, and has a number of massive downsides. It's going to be endian specific, it can't represent complex relationships between objects, it's not going to have any versioning support, the list goes on.

Once you start trying to address the above issues, you end up realising the problem is a bit larger than you thought, and end up re-creating something like google's Protocol Buffers, or Real Logic's Simple Binary Encoding, so you are better off using an established framework which then involves understanding how these work. At this point, you've kind of added back the complexity of the text based serialisation/deserialisation approach, so API wise it's not a great win. Performance wise though, something like SBE is leaps ahead of native serialisation if you don't need the flexibility that native serialisation supports (with it's polymorphism etc). Do check out SBE if you are wanting a lightish and performant mechanism, it's worked well for me (https://github.com/real-logic/simple-binary-encoding)

Seem to have gone a little away from the original point, apologies.

Re:It is only a problem if

[HiThere]

You're assuming that you determine the inputs. Actually there are ways around it, but they all involve eliminating lots of kinds of things being serialized or deserialized. YAML is safe. Python's ast.literal_eval is safe. Various others. But they don't allow arbitrary things to be de-serialized. And Ruby also has safe ways to handle this. (YAML is available in Ruby.)

But you need to realize that serialization isn't magic, and validate your imports before executing them. So arbitrary binaries can only be deserialized as byte arrays, or something essentially similar.

Re:No

[epyT-R]

Most of the developers I've met are clueless about systems and security..and the systems people I've met know very little about software design. The ones who have at least some experience in both tend to be the brightest at learning more about either.

Re:Liberats

[gweihir]

And there you nicely show that you are part of the problem, because you completely misidentified the issue.

Programming is about automation

[lucasnate1]

This has nothing do with serialization, which is just as much as serialization when written by hand. This has something to do with trusting inputs. One should not trust input that the user can control. If one only saves internal records to disk, automated serialization is welcome.

And in general, it would be good if programmers stop hating processes for automating code. The whole point of coding, and programming, is automating things. If you insist on doing things by hand, why not try your hands at doing construction work or something that actually CAN'T be automated?

Re:Seriously?

[Narcocide]

The news is that Ruby itself, without any additional third-party libraries, exposes you to attacks that it was designed to prevent, which were fixed in PHP years ago. But importantly, back then even when it was known to be unsafe, PHP warned against using it in unsafe ways. Ruby on the other hand said "don't worry we got your back" but apparently actually didn't.

Re:Seriously?

[Tyger-ZA]

The news here is that we have _still_ not managed to assure any level of real skill in the people writing software. This cannot continue.

Correct, but to elaborate: The news here is that some framework vendors have provided a feature to unsuspecting developers of varying levels of ability, these unsuspecting developers are using the feature that can be reasonably expected to have been tested thoroughly by said vendor. Meanwhile, some of these vendors have written the same feature badly, and these unsuspecting developers who definitely don't have the time to code review the entire framework, and likely don't have access to the source and/or don't know what sort of problems to be looking for anyway, are blindly trusting the vendor to provide quality code.

Part of the problem is having several vendors all competing for developer mind share, providing their own abstractions on top of how_a_computer_actually_works, and also providing lock in so that the developer finds it hard or impossible to get rid of the framework, while another part of the problem is that some developers depend on their framework training wheels and never learn how to work without it (web development is especially rife with this)

Re:It is only a problem if

[angel'o'sphere]

I serialize some objects to a file.

You deserialize them, recreating "similar" objects in memory.

What exactly is the security risk?

Sorry, gweihir: you have no clue

But I answer it for you: there is none. There is no fucking difference if you read a text file I wrote (which is called serialization, too) or a serialized object format.