Date: Fri, 4 Jan 2013 14:56:28 -0800 From: Seth Arnold <seth.arnold@...onical.com> To: cve-assign@...re.org Cc: clopez@...lia.com, oss-security@...ts.openwall.com, tenderlove@...y-lang.org, Nico Golde <nion@...ian.org> Subject: Re: Re: SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664) CVE-2012-5664 has been referenced in at least one published security update to refer to the "root" problem in Active Record's dynamic finders: http://lists.debian.org/20130104221128.GA24542@ngolde.de Are there any updates on the "draft" resolution proposed below? (I'm reluctant to change our triage to reflect the draft below until I've heard more details; our data currently matches the published DSA.) Thanks On Thu, Jan 03, 2013 at 03:53:47PM -0500, cve-assign@...re.org wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Repurposing CVE-2012-5664 to match the official advisory from the Ruby > on Rails core team is problematic because that would change the > affected product. Many CVE consumers have processes for using CVE that > can't cleanly handle all arbitrary types of post-publication changes > to the affected product. In this situation, taking a published CVE and > changing the affected product from "the Authlogic gem" to "Ruby on > Rails" is not something that we'd like to do. > > The official advisory, i.e., > > https://groups.google.com/group/rubyonrails-security/msg/23daa048baf28b64?dmode=source&output=gplain > > is obviously an important vendor disclosure about an important > product, and there will be a CVE entry that corresponds to this vendor > disclosure. See below. > > Our understanding is that some details of the Authlogic gem do have > security concerns for some people. These are perhaps alluded to by > "The injection interfaces are documented and the programmer is not > supposed to pass user input to those interfaces" and subsequent > statements in the > > http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ > > post. This may be mostly relevant at sites that, for whatever reason, > are staying at 3.2.9 for now. In any case, tracking an Authlogic gem > issue may be worthwhile for some CVE consumers. It may meet our > definition of a vulnerability even if it doesn't meet your definition > of a vulnerability. A maintainer of the Authlogic gem is, of course, > welcome to dispute this, and the related entry (see below) would then > be marked as "DISPUTED" in CVE. > > The outcome we're planning will be similar to this draft content: > > > CVE-2012-5664 > > ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: > CVE-2012-6496, CVE-2012-6497. Reason: this candidate was intended for > one issue, but the candidate was publicly used to label concerns about > multiple products. Notes: All CVE users should consult CVE-2012-6496 > and CVE-2012-6497 to determine which ID is appropriate. All > references and descriptions in this candidate have been removed to > prevent accidental usage. > > > > CVE-2012-6496 > > MLIST:[rubyonrails-security] 20130102 SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664) > https://groups.google.com/group/rubyonrails-security/msg/23daa048baf28b64?dmode=source&output=gplain > > MISC:http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ > > 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. > > > > CVE-2012-6497 > > MISC:http://phenoelit.org/blog/archives/2012/12/21/let_me_github_that_for_you/index.html > MISC:http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ > > The Authlogic gem for Ruby on Rails, when used with certain versions > before 3.2.10, makes potentially unsafe find_by_id method calls, which > might allow remote attackers to conduct CVE-2012-6496 SQL injection > attacks via a crafted parameter in environments that have a known > secret_token value, as demonstrated by a value contained in > secret_token.rb in an open-source product. > > - -- > CVE assignment team, MITRE CVE Numbering Authority > M/S M300 > 202 Burlington Road, Bedford, MA 01730 USA > [ PGP key available through http://cve.mitre.org/cve/request_id.html ] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (SunOS) > > iQEcBAEBAgAGBQJQ5e4PAAoJEGvefgSNfHMdtwoIAINP7Dj8Y6ImlbBb4JxCoIcG > StfgLRXxiPY1iFRwOvw9i1dmfleC/5bZ+PXXM1td8CQUTivklUUboWydUcIoO/hd > QjrLxzoLdNg2iqrxW+4l62wtKMt5EepFqIfS3uGYZdepxlqztDJAhif9Y7WT2Gge > NtAVEsJWJswt+vBetcYfpFA9vx9zq5CsqeU4VMEDDujN2+fxl1wtli1iz99I1s+9 > RGd+MP/ML4Dgs0sFaltSv/3S/34ZZvuKq9CWHZ7wD2hvDxIEgkVlkK509avc91A7 > EjJbL429Zyp814i9xEY4E6+5YW/uCRUHHM/p+/X4Ph3tGFakD9AUZK6hnIng1ig= > =Mfjl > -----END PGP SIGNATURE----- > Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)
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.