This blog post details exploitation of arbitrary deserialization for the Ruby programming language and releases the first public universal gadget chain to achieve arbitrary command execution for Ruby 2.x. This will be described in the following sections which detail deserialization issues and related work, discovery of usable gadget chains, and finally exploitation of ruby serialization.
Serialization is the process of converting an object into a series of bytes which can then be transferred over a network or be stored on the filesystem or in a database. These bytes include all the relevant information required to reconstruct the original object. This reconstruction process is called deserialization. Each programming language typically has it’s own distinct serialization format. Some programming languages refer to this process by a name other than serialization/deserialization. In the case of Ruby, the terms marshalling and unmarshalling are commonly used.
The Marshal class has the class methods “dump” and “load” which can be used as follows:
The problems with deserialization of untrusted data
A common security vulnerability occurs when a developer incorrectly assumes that an attacker cannot view or tamper with a serialized object as it is an opaque binary format. This can result in any sensitive information stored within the object, such as credentials or application secrets, being disclosed to an attacker. It also frequently results in privilege escalation in the case of the serialized object having instance variables which are subsequently used for permission checks. For example, consider a
User object, containing a
username instance variable, that is serialized and may be tampered with by an attacker. It is trivial to modify the serialized data and change the username variable to a username of a higher privileged user, such as “admin”. While these attacks can be powerful, they are highly context sensitive as well as being unexciting from a technical point-of-view and are not discussed further in this blog post.
Code reuse attacks are also possible where pieces of already available code, called gadgets, are executed to perform an unwanted action such as executing an arbitrary system command. As deserialization can set instance variables to arbitrary values, this allows an attacker to control some of the data that gadgets operate on. This also allows an attacker to use a gadget to invoke a second gadget, as methods are frequently called on objects stored in instance variables. When a series of gadgets have been linked together in this manner, it is called a gadget chain.
Insecure deserialization is in the eighth spot in the OWASP Top 10 Most Critical Web Application Security Risks for 2017 but limited details have been published on constructing gadget chains for Ruby. However, a good reference can be found in the Phrack paper Attacking Ruby on Rails Applications, where joernchen of Phenoelit describes in section 2.1 a gadget chain discovered by Charlie Somerville that achieves arbitrary code execution. The technique will not be covered again here for brevity, however the pre-requisites are as follows:
- The ActiveSupport gem must be installed and loaded.
- ERB from the standard library must be loaded (which Ruby does not load by default).
- After deserialization, a method that does not exist must be called on the deserialized object.
While these pre-requisites will almost certainly be fulfilled in the context of any Ruby on Rails web application, they are rarely fulfilled by other Ruby applications.
So, the gauntlet has been thrown down. Can we remove all of these pre-requisites and still achieve arbitrary code execution?
Hunting for Gadgets
Since we want to craft a gadget chain that has no dependencies, gadgets can only be sourced from the standard library. It should be noted that not all of the standard library is loaded by default. This significantly limits the number of gadgets we have at our disposal. For example, Ruby 2.5.3 was tested and found to have 358 classes loaded by default. While this seems high, on closer inspection it is revealed that 196 of these classes have not defined any of their own instance methods. The majority of these empty classes are uniquely named descendants of the
Exception class used to differentiate catchable exceptions.
The limited number of available classes means it is incredibly beneficial to find gadgets or techniques that increase the amount of standard library that is loaded. One technique is to look for gadgets that when invoked will
require another library. This is useful as even though the
require may appear to be in the scope of a certain module and/or class, it will in fact pollute the global namespace.
If the above
Gem.deflate method was included in a gadget chain, the
Zlib library from Ruby’s standard library would be loaded, as demonstrated below:
While numerous examples exist of the standard library dynamically loading other parts of the standard library, one instance was identified that attempts to load a third-party library if it has been installed on the system, as shown below:
The following figure shows a sample of the extensive locations that will be searched when requiring a library that is not installed, including other library directories:
A more useful gadget would be one which passes an attacker controlled argument to
require. This gadget would enable loading of arbitrary files on the filesystem, thus providing the use of any gadgets in the standard library, including the
ERB gadget used in Charlie Somerville’s gadget chain. Although no gadgets were identified that allow complete control of the
require argument, an example of a gadget that allows partial control can be seen below:
The above example was unable to be utilised as
const_missing is never called explicitly by any Ruby code in the standard library. This is unsurprising as
const_missing is a hook method that, when defined, will be invoked when a reference is made to an undefined constant. A gadget such as
@object.__send__(@method, @argument), which allows calling an arbitrary method on an arbitrary object with an arbitrary argument, would evidently allow calling the above
const_missing method. However, if we already had such a powerful gadget, we would no longer need to increase the set of available gadgets as it alone allows executing arbitrary system commands.
const_missing method can also be invoked as a result of a calling
digest method of the
Gem::Package class defined in the file
lib/rubygems/package.rb is a suitable gadget as it calls
const_get on the
Digest module (although any context will also work) with control of the argument. However, the default implementation of
const_get performs strict validation of the character set which prevents traversal outside the
Another way of invoking
const_missing is implicitly with code such as
Marshal.load does not perform constant resolution in such a way that will invoke
const_missing. More details can be found in Ruby issue 3511 and 12731.
Another example gadget which also provides partial control of the argument passed to
require is shown below:
The above example was also not utilised due to the “_command” suffix and no technique being identified that allowed truncation (i.e. using null bytes). A number of files do exist with the “_command” suffix but these were not explored further as a different technique was found to increase the set of available gadgets. However, an interested researcher may find it interesting to investigate when exploring this topic.
As shown below, the Rubygem library makes extensive use of the
autoload works in a similar way to
require, but only loads the specified file when a registered constant is accessed for the first time. Due to this behaviour, if any of these constants are included in a deserialization payload the corresponding file will be loaded. These files themselves also contain
autoload statements further increasing the number of files that could provide useful gadgets.
autoload is not expected to remain in the future release of Ruby 3.0, the use in the standard library has recently increased with the release of Ruby 2.5. New code using
autoload was introduced in this git commit and can be seen in the following code snippet:
To assist in exploring this extended set of available gadgets in the standard library, we can load every file registered with
autoload with the following code:
After running the above code we take a new measurement of how many classes are available for providing gadgets, and find 959 classes loaded, an increase of 658 from the earlier value of 358. Of these classes, 511 have defined at least one instance method. The ability to load these additional classes provides significantly improved conditions to begin our search for useful gadgets.
The start of every gadget chain needs a gadget that will be invoked automatically during or after deserialization. This is the initial entrypoint to execute further gadgets with the ultimate goal of achieving arbitrary code execution or other attacks.
An ideal initial gadget would be one that is automatically invoked by
Marshal.load during deserialization. This removes any opportunity for code executed after deserialization to defensively inspect and protect against a malicious object. We suspect it may be possible to automatically invoke a gadget during deserialization as it is a feature in other programming languages such as PHP. In PHP, if a class has the magic method
__wakeup defined it will be immediately invoked when deserializing an object of this type. Reading the relevant Ruby documentation reveals that if a class has an instance method
marshal_load defined then this method will be invoked upon deserialization of an object of this class.
Using this information we examine every loaded class and check if they have a
marshal_load instance method. This was achieved programatically with the following code:
There were numerous gadgets discovered during the research, however only a small selection was used in the final gadget chain. For brevity of this blog post, a few interesting ones are summarised below:
Building the Gadget Chain
The first step in creating the gadget chain is to build a pool of candidate
marshal_load initial gadgets and ensure they call methods on objects we supply. This is very likely to contain every initial gadget as “everything is an object” in Ruby. We can reduce the pool by reviewing the implementations and keeping any that call a common method name on an object we control. Ideally the common method name should have many distinct implementations to choose from.
For my gadget chain I settled on the
Gem::Requirement class whose implementation is shown below and grants the ability to call the
each method on an arbitrary object:
Now with the ability to call the
each method we require a useful implementation of
each to get us closer to arbitrary command execution. After reviewing the source code for
Gem::DependencyList (and the mixin
Tsort) it was found that a call to it’s
each instance method will result in the
sort method being called on it’s
@specs instance variable. The exact path taken to reach the
sort method call is not included here, but the behavior can be verified with the following command which uses Ruby’s stdlib Tracer class to output a source level execution trace:
With this new ability to call the
sort method on an array of arbitrary objects, we leverage it to call the
<=> method (spaceship operator) on an arbitrary object. This is useful as
Gem::Source::SpecificFile has an implementation of the
<=> method that when invoked can result in the
name method being invoked on it’s
@spec instance variable, as shown below:
The ability to call the
name method on an arbitrary object is the final piece of the puzzle as
Gem::StubSpecification has a
name method which calls its
data method. The
data method then calls the
open method, which is actually
Kernel.open, with it’s instance variable
@loaded_from as the first argument, as shown below:
Kernel.open can be used to execute arbitrary commands when the first character of the first argument is a pipe character (“|”) as outlined in the relevant documentation. It will be interesting to see if the TODO comment directly above the
open is resolved soon.
Generating the payload
The following script was developed to generate and test the previously described gadget chain:
The following Bash one-liner verifies the payload successfully executes against an empty Ruby process, showing versions 2.0 to 2.5 are affected:
This post has explored and released a universal gadget chain that achieves command execution in Ruby versions 2.0 to 2.5.
As this post has illustrated, intricate knowldge of the Ruby standard library is incredibly useful in constructing deserialization gadget chains. 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. Alternate Ruby implementations such as JRuby and Rubinius could also be investigated.
There has been some research into Fuzzing Ruby C extensions and Breaking Ruby’s Unmarshal with AFL-Fuzz. After finishing this investigation there appears to be ample opportunity for further research, including manual code review, of the native code implementations of the
marshal_load methods shown below:
Thanks for reading, ciao Bella!