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)
Subject: Re: Authentication Bypass in ROR Ecommerce

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:
> 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.
> The fix is simple and can be found in this commit:
> Would it be possible to get a CVE assigned to this?
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_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 ]
Version: GnuPG v1.4.14 (SunOS)


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