Bug 889649 (CVE-2012-5664, CVE-2012-6496)
| Summary: | CVE-2012-6496 rubygem-activerecord: find_by_* SQL Injection | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Kurt Seifried <kseifried> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bkabrda, bkearney, bleanhar, cpelland, jialiu, jrusnack, katello-bugs, katello-internal, kseifried, lmeyer, mastahnke, mfisher, mmccune, mmcgrath, mmorsi, morazi, mtasaka, sseago, vanmeeuwen+fedora, vondruch |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-24 23:05:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 891468, 891469, 891470, 891471, 891472, 891473, 893771, 995682 | ||
| Bug Blocks: | 872346, 889650, 892883 | ||
| Attachments: | |||
Aaron Patterson reports: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/DCNTNp_qjFM SQL Injection Vulnerability in Ruby on Rails There is a SQL injection vulnerability in Active Record in ALL versions. This vulnerability has been assigned the CVE identifier CVE-2012-5664. Versions Affected: All. Not affected: NONE. Fixed Versions: 3.2.10, 3.1.9, 3.0.18 Impact ------ Due to the way dynamic finders in Active Record extract options from method parameters, a method parameter can mistakenly be used as a scope. Carefully crafted requests can use the scope to inject arbitrary SQL. All users running an affected release should either upgrade or use one of the work arounds immediately. Impacted code passes user provided data to a dynamic finder like this: Post.find_by_id(params[:id]) Releases -------- The 3.2.10, 3.1.9 & 3.0.18 releases are available at the normal locations. Workarounds ----------- The issue can be mitigated by explicitly converting the parameter to an expected value. For example, change this: Post.find_by_id(params[:id]) to this: Post.find_by_id(params[:id].to_s) Created rubygem-rails tracking bugs for this issue Affects: epel-5 [bug 891468] Created rubygem-rails tracking bugs for this issue Affects: fedora-all [bug 891469] Patches available: http://seclists.org/oss-sec/2013/q1/3 Created attachment 672189 [details]
CVE-2012-5664-2-3-dynamic_finder_injection.patch
Created attachment 672190 [details]
CVE-2012-5664-3-0-dynamic_finder_injection.patch
Created attachment 672191 [details]
CVE-2012-5664-3-1-dynamic_finder_injection.patch
Created attachment 672192 [details]
CVE-2012-5664-3-2-dynamic_finder_injection.patch
This is nice explanation of how to exploit this vulnerability: http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ This has been split into two CVEs: CVE-2012-6496 (SQL injection) CVE-2012-6497 (Authlogic unsafe find_by_id method calls) CVE-2012-5664 has been REJECTED, as per: http://openwall.com/lists/oss-security/2013/01/03/12 Common Vulnerabilities and Exposures assigned an identifier CVE-2012-6496 to the following vulnerability: Name: CVE-2012-6496 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6496 Assigned: 20130103 Reference: https://groups.google.com/group/rubyonrails-security/msg/23daa048baf28b64?dmode=source&output=gplain Reference: http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ Reference: https://bugzilla.redhat.com/show_bug.cgi?id=889649 SQL injection vulnerability in the Active Record component in Ruby on Rails before 3.0.18, 3.1.x before 3.1.9, and 3.2.x before 3.2.10 allows remote attackers to execute arbitrary SQL commands via a crafted request that leverages incorrect behavior of dynamic finders in applications that can use unexpected data types in certain find_by_ method calls. See bug #891794 for CVE-2012-6497. This issue has been addressed in following products: Red Hat Subscription Asset Manager 1.1 Via RHSA-2013:0154 https://rhn.redhat.com/errata/RHSA-2013-0154.html This issue has been addressed in following products: CloudForms for RHEL 6 Via RHSA-2013:0155 https://rhn.redhat.com/errata/RHSA-2013-0155.html rubygem-activerecord-3.0.10-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. rubygem-activerecord-3.0.11-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. rubygem-activerecord-3.2.8-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. This issue has been addressed in following products: RHEL 6 Version of OpenShift Enterprise Via RHSA-2013:0220 https://rhn.redhat.com/errata/RHSA-2013-0220.html This issue has been addressed in following products: Red Hat Subscription Asset Manager 1.2 Via RHSA-2013:0544 https://rhn.redhat.com/errata/RHSA-2013-0544.html The Red Hat Security Response Team has rated this issue as having moderate security impact in CloudForms 1.1. This issue is not currently planned to be addressed in future updates. this was closed:errata because we released errata to fix it. |
This issue was found on the Phenoelit Blog: An authlogic cookie usually uses a database stored token to identify the user. The relevant parts of the session cookie are: user_credentials_id - a numeric value which is used with "User.find_by_id()" user_credentials - a radom string which will be compared with the database field "persistence_token" in the Users table Due to the way the RoR "find_by_*" methods are defined the following SQL injection a-like issue arises: > User.find_by_id({:select =>"* from users limit 1 --"}) User Load (0.5ms) SELECT * from users limit 1 -- FROM "users" WHERE "users"."id" IS NULL LIMIT 1 => #<User id: 1, [... all the fun stuff] By knowing this behaviour we can now easily circumvent the authlogic protection with the knowledge of the "secret_token". The following cookie would give you access to an authlogic protected application: { "session_id" => "41414141", "user_credentials"=>"Phenoelit", "user_credentials_id"=>{ :select=> " *,\"Phenoelit\" as persistence_token from Users -- " } } Last man standing would then be devise/warden, which works similar to authlogic but is not exploitable in that way described above. External references: http://phenoelit.org/blog/archives/2012/12/21/let_me_github_that_for_you/index.html