Red Hat Bugzilla – Bug 954365
CVE-2013-3221 rubygem-activerecord: Data-type injection attacks due absent database column data type (input vs stored value) check
Last modified: 2015-07-31 03:03:56 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2013-3221 to the following vulnerability: The Active Record component in Ruby on Rails 2.3.x, 3.0.x, 3.1.x, and 3.2.x does not ensure that the declared data type of a database column is used during comparisons of input values to stored values in that column, which makes it easier for remote attackers to conduct data-type injection attacks against Ruby on Rails applications via a crafted value, as demonstrated by unintended interaction between the "typed XML" feature and a MySQL database. References: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3221 [2] http://openwall.com/lists/oss-security/2013/02/06/7 [3] https://groups.google.com/group/rubyonrails-security/msg/1f3bc0b88a60c1ce?dmode=source&output=gplain [4] http://pl.reddit.com/r/netsec/comments/17yajp/mysql_madness_and_rails/ [5] http://www.phenoelit.org/blog/archives/2013/02/index.html
Issue related information from Novell #816666 bug: -------------------------------------------------- "1. this is a bug in MySQL. *not* rails! *every* other language using mysql is also affected. 2. this is mitigated in https://github.com/rails/rails/commit/921a296a3390192a71abeec6d9a035cc6d1865c8 which is part of rails 3.2.12. I havent checked older branches. 3. you should force MySQL to disallow the type casting feature."
Another clarification due this from Mitre: http://www.openwall.com/lists/oss-security/2013/04/24/7
This isn't something that can necessarily be fixed: 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], Time.now) 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.
As per comment 4, this issue cannot be directly addressed in rubygem-activerecord or MySQL as the issue is in the intersection of these two applications due to type handling. Without a major restructuring of how data is handled within rubygem-activerecord or MySQL it is up to developers to write applications safely: As mentioned in the original advisory (http://openwall.com/lists/oss-security/2013/02/06/7): 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)
Statement CVE-2013-3221: Not a security issue. This issue is due to the handling of data types when passing data between rubygem-activerecord and MySQL. Applications that use rubygem-activerecord and MySQL may be affected if written in a way that exposes the issue, however any flaw would be specific to that application. For further information, please refer to https://bugzilla.redhat.com/show_bug.cgi?id=954365#c5