CIVI-SA-2016-14: Improve permissions on backend scripts

CiviCRM includes a handful of backend scripts (bin/migrate/*.php and bin/encryptDB.php) which facilitate some special workflows (such as migrating site-configurations and obfuscating the database). These scripts include security protections, but -- depending on your organizational policies -- these protections may be inadequate. CiviCRM v4.7.11+ tightens access to these scripts.

Who is impacted?

In older versions, the security of these scripts rests on three things: a username, a password, and the site-key.

In most installations of CiviCRM, the site-key is a secret known only to the system administrator. In this case, the scripts remain secure because the site-key remains secure.

However, the use of the site-key has varied over the years and among organizations. For example, the site-key is also used for REST APIs; if an organization has customizations distributed among different systems, they may be tempted to share the site-key. If you have shared the site-key, then those users have had permission to migrate site-configurations and obfuscate the database.

How does 4.7.11+ change this?

In newer versions, there are two main changes:

• The migration scripts require the permission "administer CiviCRM" (in addition to a username, password, and site-key).
• The obfuscation script is disabled. To run it, the system administrator must specifically copy or edit "bin/encryptDB.php".

What should I do if I need these scripts?

• If you have any users or use-cases for "bin/migrate/*.php", ensure that the users have permission "administer CiviCRM".
• If you have any use-cases for "bin/encryptDB.php", copy the file to your own source tree. Edit it to meet your workflow+security needs.

What's the future of "bin/migrate/*.php" and "bin/encryptDB.php"?

The security team usually patches security issues with an aim to protect backward-compatibility, but in this case we seriously debated removing the scripts. On one hand, the functionality may be useful to some users, and we need to keep the files for backward-compatibility. On the other hand, these particular files have little or no test-coverage, they deviate from normal Civi architecture, they're not widely discussed, and we believe that there are better ways to address these use-cases.

Ultimately, we decided to maintain compatibility for now -- but they are tentatively deprecated. If you use these scripts, then please start a conversation about how to maintain or replace this functionality in the future.