Follow @Openwall on Twitter for new release announcements and other news
[<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

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.