Deserialization Issues Also Affect Ruby -- Not Just Java, PHP, and .NET (zdnet.com)
62
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.
"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.
Re: (Score:3)
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.
Dropping support?!? (Score:1)
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: (Score:2)
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: (Score:2)
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: Dropping support?!? (Score:3)
That's what you get for being lazy. (Score:3)
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: (Score:3)
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 ea
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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. (Score:4, Insightful)
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. (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Programming is about automation (Score:2)
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 con
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
And there you nicely show that you are part of the problem, because you completely misidentified the issue.
Re: (Score:1)
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 do
Re: (Score:1)
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.
It boils down to (Score:5, Insightful)
Re: (Score:2)
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: (Score:2)
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,