Preventing Unwanted Plugin Calls in FileMaker

The fmplugin extended privilege setting

In December 2020, FileMaker Pro 19.1.2 introduced a new feature that has not seen a lot of attention, judging by the lack of conversation and content. And it is an important security feature, so we wanted to make it gets a bit more coverage.

The fmplugin feature helps protect your solutions from exposure to plugins making unwanted calls to your files.

This change in behavior introduced with this feature fits with the overall security approach of disallowing actions until you explicitly allow them.

What Kind of Calls Are We Talking About Here?

Plugins can trigger scripts and use SQL queries to retrieve, add, and modify data. Some popular plugins with this capability are the free BaseElements plugin and the commercial MBS plugin, but there are many others. We will use these two in our examples below.

This is a risk to your solution, considering these plugins can do that from one file and target another file. They can do that without requiring a file reference from the source file to the target file. It works without requiring prior authorization between the two files.

How it was before

Here is the scenario: you have two files that unrelated in any way. There is no file reference between them and no prior authorization granted in the target file’s File Access section. And the target file requires a Full Access privilege to use references to it, as you will see in the screenshot below.

That setting named Require Full Access privileges to use references to this file will stop anyone trying to use this file from another file through normal FileMaker methods such as adding a Table Occurrence or calling a script with the normal Perform Script script step. But it does not stop plugins from making calls.

In the file that the plugin will target, the user’s extended privileges are just the standard ones; no custom extended privileges were added:

You have another file with the script shown below, and the script uses plugins to call a script in the target file. Line 7 uses the BaseElements plugin and line 10, the MBS plugin, to run a script named target_script in the plugin_target file.

When you are logged into the plugin_target file with privileges that allow you to run scripts, the script that runs from the source file will successfully execute the target_script in the target file. This works despite not having any pre-existing connection between the two files. It does not trigger the normal File Access protection mechanism.

SQL Queries

The same applies to SQL queries executed from plugins in the same fashion. There are often good business reasons for such a construct whereby two files can exchange data and execute each other’s scripts without any type of connection. (We tend to prefer using the available FileMaker Server APIs for this).

You risk an attacker guessing your script names (and open your file with sufficient privileges to run scripts if you use auto-login or ersatz security mechanism) and then run those scripts from any other file through the use of plugins.

Better protection: the new fmplugin extended privilege

FileMaker 19.2.1 aims at helping developers defend against this by blocking this type of access by default and allowing developers to make choices about which plugins they want to allow access to their solution from the outside.

All files created with 19.2.1 or newer contain a new fmplugin extended privilege:

In older files, you can add it manually to benefit from the same level of protection.

In your privilege sets, the extended privilege is turned off by default. A plugin trying to run a script or execute a SQL query from another file is not allowed and will fail.

So far, so good, loophole closed.

But what if you have a genuine need to allow a plugin from one file to work with another file?

You have some options to allow this to happen. FileMaker will evaluate different settings in a preset order to determine whether the plugin call is allowed.

The first option is to grant file-level authorization. With the fmplugin privilege in the target file unchecked, executing the plugin call will prompt you for authorization. If you decline, the call will fail.

If you have Set Error Capture On, the call will silently fail, and Get(LastError) will remain 0. You will need to check the output from the plugins to check for errors. Each plugin reports this differently.

Authorizing Two Files

If you authorize the two files (which requires Full Access rights to the target file), the fmplugin setting will no longer play a role in any future plugin calls; you have explicitly given the authorization to use the target file from the source file.

If you do not want to authorize the two files at this high level and you want some more fine-grained control over the permissions, then you can choose to enable the fmplugin extended privilege of the user’s privilege set in the target file:

When you do that, all plugin calls are allowed, provided that you are logged into the target file with an account that has a privilege set with the fmplugin extended privilege turned on. This allows calls from any plugin. And perhaps that is still not granular enough; perhaps you only want to allow calls from a particular plugin.

Create a New Extended Privilege

To make that work, you need to create a new extended privilege that starts with fmplugin and appends the unique 4-character code of the plugin.

You can get that code from the plugin vendor, or if you are running FileMaker Pro 19.2.2 or later, you can use the new Get(InstalledFMPluginsAsJSON) function to retrieve the code. The code is listed as id in the JSON section for the plugin you want to allow:

In your FileMaker file, add an extended privilege for the BaseElements plugin by appending that code to the fmplugin string (note that the plugin vendor code is case sensitive):

And make sure it is selected for the privilege set of the account used by the target file and uncheck the generic fmplugin extended privilege:

With this, you would expect that calls originating from the source file that use the BaseElements plugin will work. Those from the MBS plugin will fail.
But that is not the case. Both will still fail.

FileMaker scans the extended privileges in order; the first one it reads here is the generic fmplugin, set to disallow all plugin calls. FileMaker will stop at this setting and block the plugins from proceeding.

You will have to delete the fmplugin extended privilege to make sure FileMaker can evaluate the custom privilege for the BaseElements plugin. After deleting the fmplugin extended privilege, only the BaseElement-specific one remains in the user’s privilege set

The BaseElements call from the source file will now succeed (result = 0, which is BaseElement’s version of “ok”). The MBS plugin call will fail:

Different levels of protection kick in depending on the combination of the available settings.

Scenarios in Which the BaseElement Plugin Call My Fail

Here are some scenarios in which the BaseElements plugin call may fail (assuming no file-level authorization has been set):

In the user’s privilege set (in the target file)

Reason why the call for the BaseElements plugin will fail:

• Its specific fmpluginGyBE extended privilege is listed first, and it is disabled. When the target file receives a call from the plugin, it will stop there. The generic fmplugin setting does not get evaluated.
• The MBS plugin call will work because it does not have a specific extended privilege, and the enabled generic fmplugin covers it.

In the user’s privilege set (in the target file)

Reason why the call for the BaseElements plugin will fail:

• The generic fmplugin extended privilege is disabled, and when the call from the plugin comes in, FileMaker will stop there.
• The MBS plugin call will also fail.

Let’s recap how the decision is made in this decision tree:

Conclusion

The fmplugin and fmpluginXXXX features close an important potential loophole in your solution’s security. We highly recommend evaluating how this could affect your solutions and whether you can use this to tighten up the security in your apps.

In order to benefit from this enhanced protection, your clients need to be running at least 19.2.1. If this level of protection is important to your solution, set the minimum version required to open your solution in your file’s options to 19.2.

Contact our team to learn more about this feature and how to implement it in your FileMaker solution.