Fixing security vulnerabilities (7th jan 2014)

Steve Kenworthy edited this page Feb 11, 2014 · 2 revisions

Fixing security vulnerabilities (7th Jan 2014)

Several serious security flaws have been discovered which affect all prior versions of Fat Free CRM. This advisory is in addition to Fixing security vulnerabilities (27th Dec 2013)

The flaws reported in the previous security advisory (27th Dec, 2013) prompted us to conduct a security audit of the entire Fat Free CRM codebase. The audit has now been completed and this announcement contains the issues that were discovered and addressed. You should review this carefully and are strongly advised to upgrade to the latest release as soon as possible. Please see Upgrading Fat Free CRM for general details on upgrading from older versions.

If you find vulnerability in Fat Free CRM, please report to


The following serious issues have been discovered:

  • unprotected user create method - it is possible to craft a POST request to create a user signup even if signup is explicitly turned off in settings CVE-2014-1862
  • unprotected user edit/update method - it is possible for one user to update the details of another user CVE-2014-1863
  • the list of users' names and usernames is exposed via a javascript tag in the html of 'anonymous views' - e.g. login page / password reset page CVE-2014-1864

Other fixed issues:

  • various sensitive fields are now excluded from logs password_hash, password_salt, password_confirmation) CVE-2014-1865
  • consider_all_requests_local had been set to true in production mode (default is now false) CVE-2014-1866
  • secret token no longer requires rake ffcrm:secret to be run
  • website updated to include info on how to responsibly report security vulnerabilities


Please upgrade your instance immediately to the latest gem versions 0.13.1 and 0.12.2 or grab the latest code from the github master branch.


For those who are unable to upgrade immediately, you can apply the following patches to your code via cherry-picking.

git fetch origin
git cherry-pick 6a4ba78c3335e6df741d714ffd7a8168de2af1e8 - fix security holes in Users controller
git cherry-pick 518406fef98cb8ccf2d1fa5cf12b06305e30e921 - refactored secret token to be automatically generated
git cherry-pick a96671093f6e186ad21c6bc102a40463ed8b0928 - removed user list from logged out pages
git cherry-pick f071199b456f44736ec8df11986dd0633f12694e - prevent logging of password_hash, password_salt, password_confirmation from Rails logs
git cherry-pick 025a113b77eb2aad86495b419a4484e84e6f38c3 - consider_all_requests_local defaults to false

More details

Users controller (6a4ba78c3335e6df741d714ffd7a8168de2af1e8)

It was discovered that the UserController#create method was not protected by the can_signup? function. This meant that even if :user_signup: :not_allowed was specified in config/settings.yml, it would still be possible to create a new user signup via a specially crafted POST request.

The #new action was protected by can_signup? function and therefore the route /users/new was not available if can_signup? was false. As a result, it was not possible for a user to view the signup form if this functionality was disabled but, nevertheless, user creation via a specially crafted form POST to UsersController#create was still possible.

Furthermore it was discovered that there was no edit/update security on the UsersController. This enabled any logged in user to be able to edit any other logged in user. Whilst the admin flag was protected and users could not elevate their privileges, it was possible for a user to update the email address of an admin and subsequently reset their password, whereby gaining administrator access to the system.

The fix for both of these flaws involved fully integrating CanCan authorization and removing the before_filters that previously controlled access.

User lists on logged out pages

Fat Free CRM allows users to be quoted in comments e.g. Typing '@username' in a comment would cause the comment to be emailed to the specified user. The javascript array that contained the set of usernames had been inserted in the html head of every page in FFCRM. This meant that usernames were disclosed on anonymous views such as login and password_reset. The current patch requires you to be logged in before this list is generated, but it is likely this functionality will be reviewed in the future.

Secret token refactoring

In the previous security advisory, we implemented a system that required you to generate a secret token before Fat Free CRM would start. This meant that the first rails server start of FFCRM would always raise an error prompting you to run rake ffcrm:secret. The code has now been revised and the secret token is automatically generated for you on the first run. It is saved to Setting.secret_token and used on subsequent restarts.

Note: this will only happen when FFCRM is being run in application mode NOT engine mode. In Engine mode, Fat Free CRM uses the same secret token as the rest of the rails app it is mounted into.

Sensitive fields excluded from logs

Rails provides the ability to mask certain form parameters from the logs. See config.filter_parameters in config/application.rb

password_hash, password_salt, password_confirmation have been added to the list. You should delete your existing rails logs in rails_root/log/*.log and restart your rails server to generate new/empty log files.


This value is set in config/environments/production.rb and should generally be set to false in production environments. If it is set to true, it causes Rails, amongst other things, to provide more debugging information in 404 and 500 error pages. e.g. file paths on your local server to the code that failed or rails view folders that were checked for a missing page. This exposed information about server setup that could be of use to a hacker.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.