Object Injection

Deserializing untrusted data allows the injection of arbitrary Ruby objects, which can cause the program to execute malicious commands on behalf of an attacker.

Object injection vulnerabilities occur when untrusted data is not properly sanitized before being passed to a function that deserializes data such as YAML.load(). Attackers could pass specially crafted serialized strings to a vulnerable YAML.load() call, resulting in arbitrary Ruby objects being injected into the program, as long as the class is loaded into the application at the time of deserialization. This may open up a whole heap of various attack opportunities, such as bypassing validation logic to find cross-site scripting vulnerabilities, allow SQL injection through what appear to be hardcoded values, or even full code execution.

Example 1: The following code shows a Ruby class that creates a SQL query using its attributes that is then queried against the database. There is also an insecure call to YAML.load() with user-supplied data.

...
class Transaction
  attr_accessor :id
  def initialize(num=nil)
    @id = num.is_a?(Numeric) ? num : nil
  end

  def print_details
    unless @id.nil?
      print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
    end
  end
end

...
user = YAML.load(params[:user]);
user.print_details
...

In Example 1, the application may be expecting a serialized User object, which also happens to have a function called print_details, but an attacker may actually provide a serialized version of a Transaction object with a predefined value for its @id attribute. A request such as the following can thus allow bypassing of the validation check that attempts to make sure @id is a numeric value

GET REQUEST:  http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A

If we see the decoded version of this, we see that the user parameter is assigned !ruby/object:Transaction\nid:4 or 5=5\n.
Now deserializing the user parameter will create an object of type Transaction, setting @id to "4 or 5=5". When the developer believes they will be calling User#print_details(), they will now be calling Transaction#print_details(), and Ruby's string interpolation will mean the SQL query will be changed to execute the query: SELECT * FROM transactions WHERE id=4 or 5=5. Due to the extra clause that was added, the query evaluates to true and will return everything within the transactions table instead of the single row that was intended from the developer.

Attackers may chain different classes declared when the vulnerable YAML.load() is being called using a technique known as "Property Oriented Programming", which was introduced by Stefan Esser during BlackHat 2010 conference. This technique allows an attacker to reuse existing code to craft its own payload.