Unexpected but expected behavior

AMFI logic inconsistency for restricted binaries on macOS

INTRO

I tested different things while learning how the AMFI works. This is not only in the context of security but also in learning about the logic that is implemented behind it. The article with my notes you can find here:

Snake&Apple VI — AMFI

I wrote a small script that utilises CrimsonUroboros to check how the flags behave during this learning process. Its source code is provided at the bottom of the article. The part of the output from the tool looks like this:

./hello_2000 # Executable with 0x2000 Code Signature bit set being tested

After finishing, I could upload the results to Excel and check without looking at the kext code, which flags exclude each other. Such a situation could indicate potential irregularities in the AMFI logic:

This resulted in four unexpected behaviors that should not exist in the mechanism logic. I reported this to Apple, but as I could not exploit it or make any impact on that, the report was closed as expected behavior.

In my opinion, each subsequent bitmask should impose another security layer. However, we can observe exceptions to this rule in a few cases below.

TECHNICAL DETAILS

The binary file with Code Signature flag bits set to CS_RESTRICT (0x800) is considered restricted, which means Dyld will execute the pruneEnvVars function while loading the binary.