Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 06 Feb 2013 18:19:46 -0700
From: Kurt Seifried <>
CC: Michael Koziarski <>,,
        Steven Christey <>
Subject: Re: Potential Query Manipulation with Common Rails

Hash: SHA1

Just a heads up, the CVE situation for these issues is complicated
(multiple languages/interfaces/backends/applications are affected in
various combinations). Mitre is aware of it and working on a response,
so until then I'm holding off on assigning any CVEs.

On 02/06/2013 03:51 PM, Michael Koziarski wrote:
> Common patterns used in Ruby on Rails applications could allow an 
> attacker to generate SQL that, when combined with some database 
> server's typecasting code, generates queries that match incorrect
> records.
> Note: This is a code and best-practise advisory, there is no patch
> to apply or updated version to install.
> Databases Affected:  MySQL, SQLServer and some configurations of
> DB2 Not affected:        SQLite, PostgreSQL, Oracle
> Outline ------- When comparing two values of differing types most
> databases will either generate an error or return 'false'.  Other
> databases will attempt to convert those values to a common type to
> enable comparison.
> For example in MySQL comparing a string with an integer will cast
> the string into an integer.  Given that any string which isn't an
> invalid integer will convert to 0, this could allow an attacker to
> bypass certain queries.
> If your application has XML or JSON parameter parsing enabled, an 
> attacker will be able to generate queries like this unless you
> take care to typecast your input values.  For example:
> User.where(:login_token=>params[:token]).first
> Could be made to generate the query:
> SELECT * FROM `users` WHERE `login_token` = 0 LIMIT 1;
> Which will match the first value which doesn't contain a valid 
> integer. This vulnerability affects multiple programming
> languages, and multiple databases, be sure to audit your other
> applications to see if they suffer the same issues.
> Work Arounds ------------ There are two options to avoid these
> problems.  The first is to disable JSON and XML parameter parsing.
> Depending on the version of rails you use you will have to place
> one of the following snippets in an application initializer
> Rails 3.2, 3.1 and 3.0: 
> ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) 
> ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::JSON)
> Rails 2.3: ActionController::Base.param_parsers.delete(Mime::XML) 
> ActionController::Base.param_parsers.delete(Mime::JSON)
> If your application relies on accepting these formats you will have
> to take care to explicitly convert parameters to their intended
> types. For example:
> User.where(:login_token=>params[:token].to_s)
> Fixes ----- Unfortunately it is not possible for ActiveRecord to
> automatically protect against all instances of this attack due to
> the API we expose. For example:
> User.where("login_token = ? AND expires_at > ?", params[:token], 
> Without parsing the SQL fragments it is not possible to determine
> what type params[:token] should be cast to.
> Future releases of Rails will contain changes to mitigate the risk
> of this class of vulnerability, however as long as this feature is
> still supported this risk will remain.
> Credits ------- Thanks to joernchen of Phenoelit for reporting this
> to us and to Jonathan Rudenberg for helping to review the
> advisory.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.13 (GNU/Linux)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.