The Ruby on Rails team released versions 4.2.5.1, 4.1.14.1, and 3.2.22.1 of the framework last week to address multiple issues in Rails and rails-html-sanitizer, a Ruby gem that sanitizes HTML input. Even though the team released fixes addressing four vulnerabilities in Rails 3.x, it warned that the 4.1.x and 4.2.x series are the only ones under active support and users on older versions should move their applications immediately.
"Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases," Aaron Patterson, a well-known Ruby and Rails contributor, wrote in a security advisory.
The team also updated the public beta of Rails 5.0 with version 5.0.0.beta1.1 fixing the security flaws. Information about the severity of the vulnerabilities in the form of Common Vulnerability Scoring Standard scores were not readily available. The advisories did not indicate any of these exploits were being targeted in the wild.
Fixes arrive for multiple issues
The object leak vulnerability for wildcard controllers in Action Pack (CVE-2015-7581) affects all versions of Ruby on Rails between 4.0.0 and 5.0.0.beta1. Older versions and the beta version of Rails 5.0 are not impacted. Objects may be leaked globally if users have a route containing the string "controller," which can lead to unbounded memory growth.
A timing attack vulnerability in the basic authentication support in Action Controller (CVE-2015-7576) can let attackers analyze the time it takes an application to authenticate users and guess the password. The issue exists in the way Action Controller compares user names and passwords in basic authentication authorization code. Applications with http_basic_authenticate_with method calls are potentially vulnerable to attack.
There's a possible object leak in Action Pack (CVE-2016-0751) that can lead to a denial-of-service attack. A carefully crafted accept header can cause a global cache of MIME types to grow indefinitely. All versions of Rails are affected, and users should update to versions 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, or 3.2.22.1.
An issue in how the nested attributes in Active Record handles updates can allow attackers to set attributes to invalid values or clear all attributes on an object (CVE-2015-7577). Typically, applications using the nested attributes feature in Active Record can make sure associated records are not destroyed by passing the allow_destroy: false option to the accepts_nested_attributes_for method. This is the case because the _destroy flag prevents the :reject_if procedure from being called because it assumes that the record will be destroyed anyway. If :allow_destroy is false, then the changes to the record that should be rejected wind up being applied. This vulnerability does not affect Rails versions 3.0 and older.
"The severity will be dependent on how the application has used this feature," Patterson said.
Code using Active Model-based models, including Active Record, that does not properly validate user input before passing it to the model is potentially vulnerable to attack (CVE-2016-0753). Active Model and Active Record objects are not equipped to handle arbitrary user input, so applications have to verify input beforehand, according to the advisory. While the vulnerability affects Rails versions 4.1.0 and newer, applications using Strong Parameters will generally not be impacted because they whitelist parameters. Strong Paramters also require applications to specifically opt out of input verification with the `permit!` method to allow mass assignment.
Issues in HTML sanitizer
The team also released version 1.0.3 of rails-html-sanitizer, a Ruby gem that sanitizes HTML input for Rails applications, to address three cross-site-scripting vulnerabilities.
Attackers can potentially launch an XSS attack by sending carefully crafted strings that can bypass the whitelist sanitizer (CVE 2015-7580). Another issue in the whitelist sanitizer where certain attributes are not removed from tags when they are sanitized can also lead to an XSS attack on target applications (CVE 2015-7578). And the final XSS flaw was in the way the Rails::Html::FullSanitizer class was implemented (CVE 2015-7579). An attacker could pass an already escaped HTML entity to the input of Action View's strip_tags, which could cause a XSS attack. Members of GitHub and Zendesk teams were credited with reporting the vulnerability.
The Rails team also warned the HTML sanitizer "was inadvertently made much more permissive" in Rails 4.2 than it was in 4.1. In order to rectify the mistake, the team had to make a backward-incompatible change to the sanitizer.
"If you use the sanitizer in 4.2, you will need to verify that the more restrictive filter still permits all the tags you need to allow," the team wrote in the blog post. Missing tags can be added manually to the whitelist.
Automated scanners can detect issues
The directory traversal and information leak vulnerability in Action View (CVE 2016-0752) is an especially interesting flaw that affects applications that pass unverified user input to the render method in a controller. Attackers can send carefully crafted requests to cause the application to render files from unexpected places like outside the application's view directory. The information leak vulnerability can lead to a remote code execution attack, according to the advisory.
While developers should not be passing user input directly to a file handling function, it happens often enough that it makes sense for Rails to prevent raw input from being passed around without sanitizing it first. This flaw is a good example of why developers should use Burp's core scanner or static analysis security scanner Brakeman to scan their code as they write. Burp and Brakeman already had checks to throw a warning when detecting this kind of directory traversal issue.