The popular Ruby on Rails (Rails) web application framework has a vulnerability (CVE-2013-0156) in the parsing of XML parameters that allows an attacker to reach code execution on the webserver that runs the Ruby on Rails framework. Attackers are able to bypass authentication, inject and execute SQL or programming code, and can extract data and or gain control over the web application. All Rails applications in general are susceptible to the attack as XML parameter parsing is on by default. There is risk for the businesses running on Rails and more generically the potential for widespread, automated infections.
Exploits are publicly available and are already been integrated into vulnerability testing frameworks such as Metasploit. It underscores the fact that this vulnerability is easy to attack and should be treated as an high priority threat.
If an organization runs an application under the Rails framework, there are two primary risks:
- data loss: the attacker can access and extract all data the application has access to, which can lead to privacy violations through the loss of customer data and revenue impacts through the loss of business data, intellectual property, etc
- webserver control loss: the attacker takes administrative control of the webserver, which allows him/her to monitor ongoing transactions and harvest user credentials or use the machine in outbound attacks, for example see the recent attacks on US banking sites that had a strong server component (see here for a example in the NY Times)
Organizations should not only check on internal applications but also on third party applications that they run and see if they are developed in Rails and if a patch is available. Because Rails is such a popular framework it is quite possible that external applications (think SaaS as for example) are also impacted.
Organizations that have vulnerable installations have a number of choices. The primary option is to upgrade to the latest version of Rails 3.2.11 which addresses this vulnerability. However, there have been some reports of application problems (JSON arrays in particular) introduced by the new version, so one needs to make sure that all aspects of the application continue to function as expected. Application owners that cannot upgrade directly because they run on an older version of Rails (i.e. V2.3, v3.0, V3.1) can apply a patch that has been made available by the Rails team. If the application owner can neither upgrade or patch, the application itself can be hardened to prohibit XML parameters at all, or at least prohibit the parameter conversions that have caused the particular problem (YAML and Symbol), Instruction on how to configure the application are available in the Rails advisory for the vulnerability.
Even organizations that patch their infrastructure might evaluate to implement the hardening of the application in any case. Parsing of XML is notoriously difficult (see the recent MS12-002 for example) and if the application can safely function without that capability it is a good defensive measure to eliminate it.
Qualys detects the vulnerability as QID 12639 – Ruby on Rails Action Pack Multiple Vulnerabilities. We suggest that you scan your entire external perimeter and internal webservers to pinpoint your vulnerable assets.
