Deserialization issues also affect Ruby, not just Java, PHP, and .NET

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.

The issue at the heart of this problem is how Ruby handles the process of serialization –and its counterpart, deserialization.

Serialization is the process of converting a data object into a binary format so it can be sent over a network, stored inside a database, or saved on disk. As you might imagine, deserialization is the opposite process, of reversing a binary blob back into its data object structure that can then be fed back into the programming language for further processing at a later date.

Almost all programming languages support serialization and deserialization operations. Some might use different names for these processes, but the concept is found in almost all. For example, in some Ruby documentation files, some developers refer to serialization and deserialization operations under the terms of marshaling and unmarshalling data.

Serializing and deserializing data is a common operation in many web or desktop applications, mainly because it’s an incredibly easy and fast way of moving data between apps or different programming mediums.

But security researchers have sounded the alarm about the improper usage of these two operations. It’s now been known for years that this process could be targeted to trick applications into running malicious commands, especially when user-supplied data is fed directly into a serializer without being sanitized first, and then deserialized into a chain of automated operations with no security safeguards.

The Java Apocalypse

This became painfully obvious in 2015 when two security researchers –Chris Frohoff and Gabriel Lawrence– discovered a dangerous flaw in the way data was deserialized via the Apache Commons Collection, a very popular Java library.

Researchers from Foxglove Security expanded on Frohoff and Lawrence’s original work, showing how an attacker could exploit the Apache Commons Collection library flaw to take over WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS Java servers.

The proof-of-concept code released from these experiments was later used to confirm that over 70 other Java applications were also vulnerable to deserialization flaws. A ShiftLeft report also revealed numerous serialization/deserialization issues across many SaaS vendor SDKs.

These discoveries and the revelation that deserialization attacks could work in practice and weren’t just a theoretical attack rocked the Java ecosystem in 2016, and the issue became known as the Java Apocalypse.

Organizations such as Apache, Cisco, Red Hat, Cisco, VMWare, IBM, Intel, Adobe, HP, Jenkins, and SolarWinds, all issued security advisories and patches to fix affected products.

For the sake of security, Google allowed over 50 of its Java engineers to participate in a project named Operation Rosehub, where Google staffers submitted patches to Java libraries to prevent deserialization attacks.

Over 2,600 were patched in Operation Rosehub, but the message was heard loud and clear at Oracle’s offices, and the company announced this spring plans to drop serialization/deserialization support from the main body of the Java language.

.NET and PHP also affected

However, the issue didn’t stop with Java. In 2017, HPE security researchers also discovered that many .NET libraries for supporting serialization and deserialization operations were also vulnerable to similar attacks, which allowed hackers to take over apps and servers.

PHP followed suit a few months after that, and earlier this summer, a PHP deserialization issue was also found in WordPress, a content management system that’s being used to run more than 30 percent of the Internet’s sites.

And now, Ruby, too.

But, this week, security researchers from elttam, an Australian IT security firm, have also discovered that Ruby-based apps are also vulnerable to serialization/deserialization attacks.

Researchers published proof-of-concept code 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,” elttam 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.”

While the Java and .NET deserialization issues were limited to third-party libraries, having deserialization issues impact Ruby itself greatly increases a hacker’s attack surface.

With this week’s revelations, there is now proof-of-concept code available online for assembling serialization/deserialization attacks against four of the most popular programming ecosystems around —Java, .NET, PHP, and Ruby.

As the HPE researchers pointed out in their research paper about .NET’s serialization woes, the problem is not that simple to solve.

The serialization/deserialization issues –regardless of the programming language– are a combination of vulnerable code but also bad coding practices on behalf of developers, who fail to recognize that serialized data is not necessarily secure by default and should be trusted when deserialized.

Fixing this would require having sanitizing user input before serializing it and then limiting a deserialized data’s access to certain functions to prevent malicious code from having its way with a server.

Related coverage:

READ MORE HERE