Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 2 Jan 2014 10:16:05 +0800
From: Steve Kenworthy <steveyken@...il.com>
To: cve-assign@...re.org
Cc: Stephen Kenworthy <stephen.kenworthy@...le.oxon.org>, oss-security@...ts.openwall.com, 
	Henri Salo <henri@...v.fi>, joernchen@...noelit.de
Subject: Re: CVE request: Fat Free CRM multiple vulnerabilities

Thanks for CVE-2013-7249.

Re: "destroy", ordinarily, this would be true as that commit fragment just
removes the destroy route. However, in this case there has not been any
actual code to delete the user in this controller (user deletion is handled
elsewhere in a separate admin section). The effect of the "  , :except =>
[:index, :destroy]" commit was simply to tighten up the routes, rather than
leaving exposed a route that didn't actually perform a delete function.

Hope that makes sense. Let me know if you have any other outstanding
questions.



On Tue, Dec 31, 2013 at 10:57 PM, <cve-assign@...re.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > I can confirm for issue 3 that the disclosure also involves to_xml.
> > Please assign the additional CVE ID.
>
> Use CVE-2013-7249.
>
>
> > Re: denial of service, I don't believe this is an issue as the exploit
> > only relates to read operations.
>
> OK, there is no CVE assignment for this. Just for clarification, the
> "denial of service" theory was related to:
>
>
> https://github.com/fatfreecrm/fat_free_crm/commit/cf26a04b356ad2161c4c6160260eb870a3de5328
>
> specifically:
>
>    -  resources :users, :id => /\d+/ do
>    +  resources :users, :id => /\d+/, :except => [:index, :destroy] do
>
> and:
>
>    -   it "recognizes and generates #destroy" do
>    -      { :delete => "/users/1" }.should route_to(:controller =>
> "users", :action => "destroy", :id => "1")
>    +    it "doesn't recognize #destroy" do
>    +      { :delete => "/users/1" }.should_not be_routable
>
> in which a reader might infer that a "destroy" of some data associated
> with a user account would be a denial of service.
>
> Our understanding now is that the presence of ":destroy" in the added
> code string:
>
>    , :except => [:index, :destroy]
>
> does not prevent any type of attack, and therefore it is not a
> vulnerability fix.
>
> - --
> 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)
>
> iQEcBAEBAgAGBQJSwtq0AAoJEKllVAevmvmsd7IH/1zw1OPyRZMnweFANOFheRMg
> QfJxobXUXBHa30uZeRaOBujRNzx/ptTl0CrfyCSDpktcXQ803TW8MmfOCwEfzvym
> 8QtH41XTxkXDzVNujl5jtVCMCEw9+/zPYvvsRT9vrQPNp1F2cIkUxcggn3PGJ4Et
> Exuo83rI5ciyWgPOdB/s748PhPNRPIw8rx5zahxw9fepsxNnlXngdpGmxa6dD4YU
> NZ7pNjc2RpUq22gVcSks17/JnqetCrvkwmUgTHT0VbYhu/c+Zf7DUd/vL6uvkmxh
> GUUJsmsP/oUwmWrw8a4m2/cKFYMjORsOYK1KU2IjhtezddiiysOtg6E/eEs1SZQ=
> =RNUF
> -----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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.