Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ