Bug 832124 - (CVE-2012-2734) CVE-2012-2734 cumin: CSRF flaw
CVE-2012-2734 cumin: CSRF flaw
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20120919,repor...
: Security
Depends On: 840121 858868
Blocks: 808230 828434 828935
  Show dependency treegraph
 
Reported: 2012-06-14 11:19 EDT by Vincent Danen
Modified: 2016-03-04 07:13 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 840121 (view as bug list)
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to embed id (associated with login) in all forms to combat CSRF (6.39 KB, patch)
2012-07-17 16:22 EDT, Trevor McKay
no flags Details | Diff
Patch to embed id (associated with login) in all forms to combat CSRF (7.55 KB, patch)
2012-07-17 18:48 EDT, Trevor McKay
no flags Details | Diff
Patch to embed id (associated with login) in all forms to combat CSRF (7.12 KB, patch)
2012-07-18 18:01 EDT, Trevor McKay
no flags Details | Diff

  None (edit)
Description Vincent Danen 2012-06-14 11:19:37 EDT
Florian Weimer found that Cumin did not protect against CSRF (Cross-Site Request Forgery) attacks.  If an authenticated user logged into a Cumin web site visited a specially-crafted web page, it could lead to the unauthorized command execution in the Cumin site with the privileges of the logged-in user.
Comment 1 Trevor McKay 2012-07-17 16:22:44 EDT
Created attachment 598739 [details]
Patch to embed id (associated with login) in all forms to combat CSRF
Comment 2 Trevor McKay 2012-07-17 16:33:22 EDT
This patch should add CSRF protection.  A unique id (generated from the same source that generates session ids) is embedded in the rendering of every descendent of the Form class, unconditionally.  

The unique id is stored in the login record for the session and compared against the value in a POST request.  The name of the csrf token is based on the name of the particular form (using the standard parameter.path naming system).

The only form(s) where the token will be unset are login forms.  I suppose a CSRF attack could be used to log a user in as another legitimate user, but would this be dangerous?  The patch could be extended to initiliaze a CSRF token to use for login forms, with a reset of the id after login.  Giving it a try...
Comment 3 Trevor McKay 2012-07-17 18:48:07 EDT
Created attachment 598761 [details]
Patch to embed id (associated with login) in all forms to combat CSRF

Moved the csrf tag into the client_session but outside of the login record.  The id is set on creation and reset on login and logout.  Now all forms will have an embedded id, regardless of login state.  Tested with crafted login POST.

Note, this is starting to collide with the patch for session fixation.  The ultimate form will be a little different (messing with the csrf tag value at login will be part of the routine that resets the session id).
Comment 4 Trevor McKay 2012-07-18 12:50:05 EDT
Note on processing.  The CSRF checks are done in the processing pass on descendents of the form class.  Processing is done in depth first order over the widget hierarchy, so a form's ancestors in the hierarchy may be processed before the CSRF check fires (procesing may not be *strictly* depth first, that is a widget may take some action before calling do_process() on its children).

This means that for some forms, there is a small window where processing may happen in parent widgets before an exception is raised and processing stops in a CSRF case.  Thinking about a streamlined way to move CSRF checks to the beginning of processing....

One possibility: the csrf tags are named for the widget (path) to which they pertain.  So, scanning the POST data for csrf values gives us a list of paths to all form widgets touched in the POST (probably only one).  Pages hold lists of widgets by path, therefore we ought to be able to call methods on those widgets early (or be less general and just check the CSRF values against the client session, without the possibility of an overload).
Comment 5 Trevor McKay 2012-07-18 18:01:51 EDT
Created attachment 599010 [details]
Patch to embed id (associated with login) in all forms to combat CSRF

Greatly simplified, and early checks solved. (can you say "blinders" :) )

There is a single global well known name for the csrf tag value in forms, and it is generated and checked without any reliance on the widget and parameter classes or the widget processing methods.
Comment 6 Vincent Danen 2012-09-19 11:57:26 EDT
Acknowledgements:

This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
Comment 7 errata-xmlrpc 2012-09-19 13:43:58 EDT
This issue has been addressed in following products:

  MRG for RHEL-5 v. 2

Via RHSA-2012:1278 https://rhn.redhat.com/errata/RHSA-2012-1278.html
Comment 8 errata-xmlrpc 2012-09-19 13:52:58 EDT
This issue has been addressed in following products:

  MRG for RHEL-6 v.2

Via RHSA-2012:1281 https://rhn.redhat.com/errata/RHSA-2012-1281.html
Comment 9 Vincent Danen 2012-09-19 17:11:01 EDT
Created cumin tracking bugs for this issue

Affects: fedora-all [bug 858868]

Note You need to log in before you can comment on or make changes to this bug.