AMFI syscall

The mysterious syscall of AMFI

On macOS, one popular technique to inject code into other applications is leveraging the DYLD_INSERT_LIBRARIES environment variable, which I wrote about in 2019 DYLD_INSERT_LIBRARIES DYLIB injection in macOS / OSX. This variable can store a colon-separated list of dynamic libraries to load before the ones specified in the target process.

Several limitations apply to when this injection technique can be used and when it cannot, which I also discussed. I revisited this topic, not only because things might have changed since then but also to ensure that I didn’t miss anything. It turned out to be a wise move and a useful exercise.

The restrictions around the use of environment variables are implemented in dyld2.cpp, specifically in the configureProcessRestrictions function. When I analyzed the function in more detail, it turned out I had overlooked an important point previously.

In this post, we will cover how the dyld dynamic linker restriction decision process is different on newer versions of the OS. With that, we will uncover a previously undiscussed or undocumented AppleMobileFileIntegrity (AMFI) system call.

The following code snippet shows the entire configureProcessRestrictions function from the source code.

Listing – The configureProcessRestrictions function from dyld2

The global variables gLinkContext.allowEnvVarsPath and gLinkContext.allowEnvVarsPrint control whether environment variables will be processed or ignored by the dynamic linker. Therefore, they affect our injection mechanism. These two global variables are set by negating the isRestricted local variable (line 52-53) in the else branch at the end of the function (line 29-60). The logic of this branch is similar to older implementations of dyld and it can be summarized as follows:

The isRestricted variable is set to true (and consequently injection is blocked) if:

1. The main executable has a restricted segment (line 35-37)
2. suid / guid bits are set (line 35-37)
3. System Integrity Protection (SIP) is enabled and the program has the CS_RESTRICT flag (line 38-44) set

If the CS_REQUIRE_LV flag is set, it will lift the restrictions (line 46-49). This flag, however, indicates that library validation is active. Therefore, even if restrictions around environment variables are loosened, library validation policy will stop our injection attempts because our dylb won’t match the target process code signature.

In analyzing the else branch conditions, we can make a few considerations.

The code doesn’t deal with situations where:

1. the binary is signed with hardened runtime and,
2. unrestrictive entitlements like com.apple.security.cs.allow-dyld-environment-variables are set. This would enable environment variables regardless of hardened runtime being set.

Additionally, if SIP (System Integrity Protection) is enabled, which is the default on latest versions of macOS, this else branch will never be hit by the call flow.

So what will set the restrictions around injection in these cases, then? The answer is AppleMobileFileIntegrity (AMFI).

If we go back to the source code, we can see that there is a significant part at the beginning that refers to AMFI, including constants, variables, and a function call (line 3-28).

AMFI is a kernel extension, which was originally introduced in iOS. In version 10.10 it was also added to macOS. It extends the MACF (Mandatory Access Control Framework), just like the Sandbox, and it has a key role in enforcing SIP and code signing.

Let’s repeat that code segment here.

Listing – The AMFI related code in configureProcessRestrictions

For macOS, we can ignore the #if code blocks that are related to iOS or a simulator. These will not compile into the macOS binary, so we can remove them from the code for easier reading.

Listing – The cleaned up AMFI related code in configureProcessRestrictions

The code will start by checking whether the binary has a RESTRICTED segment. If this is the case, it changes the amfiInputFlags variable, (line 2-3) which will be passed to the amfi_check_dyld_policy_self function call later (line 12).

The internalInstall function called at line 6 in the listing above can be found in dyld-732.8/dyld3/Loading.cpp. This function will check if the SIP-related flag CSR_ALLOW_APPLE_INTERNAL is set or not by calling the csr_check function. On default installations, this is not set. csr_check will return zero if the flag is set. If it’s not, it will return a different value, which will cause internalInstall function to return FALSE, as the equal (==) condition won’t be met.

Listing – The internalInstall function in Loading.cpp

With that, the following branch in configureProcessRestrictions will be never called, as the first part of the && operation will be FALSE.

Listing – The if branch in configureProcessRestrictions will not be taken if internalInstall returns false.

amfiFake would be only set by the previously skipped branch, thus the next if branch will be also skipped.

Listing – The next if branch in configureProcessRestrictions will not be taken

At this point, the code will call amfi_check_dyld_policy_self.

Listing – The call to amfi_check_dyld_policy_self and the following code segment in configureProcessRestrictions

But what does amfi_check_dyld_policy_self do? A Google search only reveals the source code from Apple, and nothing else. Let’s investigate the source code to see if we can find out what happens when this function is called.

There is a definition in dyld2.cpp, but it only indicates that it’s an external function. We might know more about it if we had the libamfi.h header file, but unfortunately it’s not available from Apple.

Listing – The definition of amfi_check_dyld_policy_self in dyld2.cpp

There is, however, a function with this name in dyld-732.8/src/glue.c.

Listing – amfi_check_dyld_policy_self function in glue.c

Upon inspecting the code, we find a check on the gSyscallHelpers structure. If we follow gSyscallHelpers, we arrive at another header file, dyld-732.8/src/dyldSyscallInterface.h. We can see that gSyscallHelpers is a structure with plenty of function pointers, and one of them is the one we are looking for.

Listing – Part of the gSyscallHelpers structure in dyldSyscallInterface.h

Comments on both of the last two code segments indicate that they are related to an iOS simulator. The name of the structure suggests that this is a system call. Again, in a quick Google search for AMFI syscall, we can’t find anything that would reveal what this system call does, or if AMFI has any system calls in general.

If we go ahead and reverse engineer the binary, we’ll see what happens at that point. We’ll use Hopper for static analysis and lldb for dynamic.

We will start by doing static analysis with Hopper. If we open /usr/lib/dyld and look for the configureProcessRestrictions, the first thing we will notice is that it’s not there. After looking into the decompiled code, we find that this function is actually compiled inline in dyld_main. Below is an excerpt from the decompiled main function showing the key parts of configureProcessRestrictions. We added references to the first source code outline as comments.

Listing – The decompiled code of dyld`main

We can see the else branch starting at loc_6617 (read: offset 0x6617). This is the part that won’t be taken on new versions of macOS with SIP enabled. loc_65fd is where the call to AMFI will happen. Fortunately, we can disassemble or decompile _amfi_check_dyld_policy_self here, which reveals that it is a wrapper around ___sandbox_ms.

Listing – The decompiled code of amfi_check_dyld_policy_self

But what is ___sandbox_ms? It’s basically a wrapper for the __mac_syscall system call. We can go into ___sandbox_ms, and verify that there is indeed a syscall call in this function. The specified syscall number is 0x17d which corresponds to __mac_syscallsyscalls.master. The 0x2 in 0x200017d specifies the class of the syscall, a Unix/BSD-style syscall in this case.

Listing – Disassembly of ___sandbox_ms

Listing – __mac_syscall definition in mac.h

While the policyname defines which MACF module we want to call, the _call acts as an ioctl number to specify which function to call inside the module. Finally, *_arg are variable number of arguments to pass to the MACF function.

If we look back at the code in amfi_check_dyld_policy_self, the policy selector is AMFI, the ioctl code is 0x5a, and the input/output flags are passed in as arguments.

Listing – __mac_syscall parameters in amfi_check_dyld_policy_self

When the function returns, the flags will be saved in the originally provided memory location. (*rbx = *(rbp - 0x10); //amfiOutputFlags value)

Let’s verify this with dynamic analysis. Our debugger of choice for this action is lldb. We simply use a dummy Hello World C code, which only prints out one line, and we didn’t sign our compiled binary.

Listing – Starting lldb and specifying target executable

We will set a couple of breakpoints:

1. dyld main function
2. _amfi_check_dyld_policy_self

Listing – Setting breakpoint in lldb

Next, we will start our process with the run command and break at the dyld’s main entry.

Listing – Starting the process, and hitting our first breakpoint

We can continue with the continue command, hitting the AMFI call.

Listing – Hitting the breakpoint at dyld`amfi_check_dyld_policy_self

From here, we can single-step with the step instruction, and we finally hit the syscall.

Listing – Arriving to the syscall with single steps

If we single-step onward (out of the function calls), we will get to the point where the output value is saved. Recall this line from our decompiled code, where the amfiOutputFlags are saved by dereferencing a stack pointer and stored at a memory location pointed by rbx:

Listing – Setting of amfiOutputFlags in the decompiler

In the debugger, the following listing shows the same point:

Listing – Setting of amfiOutputFlags in the debugger

Here the flags are stored in rcx and their value is 0x5f. If we continue single-stepping, we will arrive back at the location where our initial else branch in configureProcessRestrictions would start. Stepping forward, we will see that the branch is not taken, as we expected, and the issetugid and other calls will be skipped:

Listing – Verifying in the debugger that the else branch is not taken

If we check the flag value of 0x5f it translates to binary 0101 1111, which means that all of the flags are set (see below for reference).

Listing – AMFI output flags related code from dyld2.cpp

If we run the same exercise for a binary that has a restricted segment, for example, we will get a result value of 0x40. This translates to none of the above flags set, which means the environment variables leveraged for injections won’t be allowed. This further confirms that this system call will properly control whether environmental variables should be ignored or not by the dynamic linker on newer versions of macOS.

The only remaining part to cover is what happens in the kernel. The AMFI kext that we need to inspect can be found at /System/Library/Extensions/AppleMobileFileIntegrity.kext/Contents/MacOS/AppleMobileFileIntegrity. We will not debug the syscall in kernel mode, only review the code via static analysis in Hopper.

The AMFI MAC (Mandatory Access Control) registration happens at the _amfi_register_mac_policy function call. The following listing shows the code for this function where we notice a call to _initializeAppleMobileFileIntegrity:

Listing – The amfi_register_mac_policy function

If we check the _initializeAppleMobileFileIntegrity function implementation, we notice that it uses the string “AMFI” for the mac_policy argument. This makes sense, as we saw the same string passed as an argument to the syscall in userspace to select the MACF module we wanted to call.

Listing – The AMFI policy registration with the kernel

The actual syscall handler is implemented in policy_syscall which receives three arguments:

Listing – The AMFI syscall handler function, policy_syscall

We can determine the type of these arguments by looking at the implementation of __mac_syscall in kernel mode in xnu-6153.11.26/security/mac_base.c:

Listing – Parts of __mac_syscall from mac_base.c

If we map mpo_policy_syscall(p,uap->call,uap->arg) to the comment section, we can determine that the first argument is the calling process, the second argument is the MAC policy-specific system call to perform, and the third argument refers to the MAC policy-specific system call arguments.

We can confirm this by looking at the same function (policy_syscall) in Hopper. rsi takes the 2nd argument (arg1). This should be the policy-specific syscall value (~ioctl value), which in our case was 0x5a. If we inspect what happens in this function, we can see that this is indeed one of the two values that is being checked for (the other is 0x5b). From there, we will have a call to check_dyld_policy_internal.

Listing – Part of the decompiled code of AMFI`policy_syscall function

If we check the check_dyld_policy_internal call, the further function names are descriptive. AMFI will do various verifications against the calling process, and essentially determine the flags.

Listing – Part of the decompiled code of AMFI`check_dyld_policy_internal function

We will not analyze each of these one by one, as it would be excessive, but one function is worth a look: macos_dyld_policy_collect_state. In reviewing it, we can see that it collects a lot of information for the calling process. It verifies many of the code signing properties of the process, including the entitlements. It’s beyond the scope of this post to analyze this in detail, but by looking through the function names and strings, we can see that it does what we expect. This is the point where all of the entitlements are also being taken into consideration, which is what we were missing originally when we were looking at configureProcessRestrictions.

Listing – Part of the decompiled code of AMFI`macos_dyld_policy_collect_state function

This function also reveals an undocumented entitlement com.apple.security.cs.allow-relative-library-loads.

To sum up, we saw that dyld uses AMFI to determine the process restrictions around injection on newer version of macOS. We verified that with both static and dynamic analysis. During our investigation, we uncovered a previously undocumented AMFI MACF policy system call.

About the Author

Csaba Fitzl has worked for 6 years as a network engineer and 8 years as a blue/red teamer in a large enterprise focusing on malware analysis, threat hunting, exploitation, and defense evasion. Currently, he is focusing on macOS research and working at OffSec as a content developer. He gives talks and workshops at various international IT security conferences, including Hacktivity, hack.lu, Troopers, SecurityFest, DEFCON, and Objective By The Sea. @theevilbit