Date: Sun, 12 Oct 2014 01:32:55 -0400 (EDT) From: cve-assign@...re.org To: tomek@...asano.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Authentication Bypass in ROR Ecommerce -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I've worked with David Henner, the Ruby on Rails Ecommerce owner to fix a > security issue in the password reset functionality of the ROR Ecommerce > application. When a user is created in the ROR Ecommerce application, > a perishable_token is generated for that user. This perishable token is > then used for password resets. Note that a password reset request never > needs to be initiated as this token is immediately available. > > Due to the way MySQL handles typecasting, it is possible to send > a token value of the integer 0 which will then match the first > perishable token in the database. The way the application is first > initialized and setup, the administrative user is the first user > to be created. This can be seen in the Getting Started section: > https://github.com/drhenner/ror_ecommerce#getting-started. As a result, > the integer 0 passed to the application will match the administrator's > account. The application then logs the matched user in and allows them > to change the password. > > This bug is the same as joernchen's example in his MySQL madness and > Rails post. > > http://www.phenoelit.org/blog/archives/2013/02/05/mysql_madness_and_rails/ > > The fix is simple and can be found in this commit: > https://github.com/drhenner/ror_ecommerce/commit/25fe5ebb2f193978e9f9967c9dfe6be5716e8650 > > Would it be possible to get a CVE assigned to this? http://www.phenoelit.org/blog/archives/2013/02/05/mysql_madness_and_rails/ has already been mapped to CVE-2013-3221. This reflects a perspective that it is a Ruby on Rails issue. Other perspectives may exist. The two main options for handling this type of situation are: 1. The 25fe5ebb2f193978e9f9967c9dfe6be5716e8650 vendor fix can be mapped to CVE-2013-3221, either by just stating that the associated vulnerability is CVE-2013-3221, or by describing the fix as a CVE-2013-3221 workaround or something similar. 2. If the vendor feels that ror-e.com ror_ecommerce itself is responsible for the successful password-reset attack (i.e., the vendor considers the lack of to_s to be a security-relevant implementation mistake, regardless of any opinions about what Ruby on Rails could or should be doing), then the vendor can have a CVE ID specific to the ror_ecommerce product. For option 2, it's not required that the vendor send e-mail here. We'll accept reasonable efforts at passing along what's been heard from the vendor. Right now, however, the available vendor statement is "add to_s just in case," and this isn't quite enough for us to conclude that the vendor wants to accept option 2. - -- 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.14 (SunOS) iQEcBAEBAgAGBQJUOhGGAAoJEKllVAevmvmsOl8IAJkUHg66x+q//kILel7b0aMq bjE/a7OmFYeFdm782JTckQHGMl8+p7ADmKM/MBhedMeRN+9xdEzhpwz8kXRB+7U2 YhlmlD4SCNae2aK4K5Ms3GfCfgoutpsNiUW3hBLHHNWosnQA8v7tvEITAynAyy/6 tYAEbGOA2Gt6PPp/b5q6g0nkmE1WLYNOtIsFZFehe1M02W5lAoVsHF2ee2I3uqU1 pFUj2uu+oGqFFgeZbuDSXW3CwkChDHWU/NQ7TCuTqWQW6TtM4RkRnkOf9TcsbHMD w7J0RGJ3amBu4MUrrtrnXU3lihfy1snpQCtFp3bx3CRQI5DuWSrUlXDpSutOlMc= =jvA3 -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ