After my recent blog post, my old mate @_Dark_Knight_ reached out to me and he asked me a question:

Dyld 0x1 Library Missing In Macomb
Dyld 0x1 Library Missing In Machine
Dyld 0x1 Library Missing In Macomb County

“Do you typically callout user apps that allow dyld_insert_libraries?”

Dyld 0x1 Library Missing In Macomb

And a few similar ones, and I will be honest, I had no idea what is he talking about, if only I understood the question :D Despite the fact that my recent blog posts and talks are about macOS, I deal much more with Windows on a daily basis, probably like 95%, and macOS is still a whole new territory for me. So I decided to dig into the question and learn a bit more about this.

As it turns out there is a very well known injection technique for macOS utilizing DYLD_INSERT_LIBRARIES environment variable. Here is the description of the variable from the dyld man document:

In short, it will load any dylibs you specify in this variable before the program loads, essentially injecting a dylib into the application. Let’s try it! I took my previous dylib code I used when playing with dylib hijacking:

Compile:

Now that you have a basic understanding of the nature of the problem we will move on towards the solutions. Make sure to implement these in the specific order in which they are provided to avoid any conflicts. DYLD, 0x1 Library missing. Ask Question Asked 9 months ago. Active 9 months ago. 2020-07-08 15:30:10.113 +0200 OS Version: Mac OS X 10.15.5 (19F101) Report Version: 12 Anonymous UUID: 85FFB3B5-2E09-2D2F-57A9-8C3D57EE830D Sleep/Wake UUID: 1B7701F9-55B5-4A58-84D4-58FD25F54B43 Time Awake Since Boot: 140000 seconds Time Since Wake: 1900.

Outlook 2016 for mac crashes upon start-up / won't open after latest High Sierra updates installed. DYLD, 0x1 Library missing. Application Specific Information. 1 Responsible: SteamCMD GUI 1052 User ID: 501 Date/Time: 2017-09-30 14:06:05.612 -0700 OS Version: Mac OS X 10.13 (17A264c) Report Version: 12 Anonymous UUID: EF153BD9-8873-42AE-90E4-75C3B8AFBCC0 Time Awake Since Boot: 17000 seconds System Integrity Protection: enabled Notes: Translocated Process Crashed Thread: 0 Exception Type: EXCCRASH.

Recently, Apple received a lot of reports regarding the 'Dyld: Library Not Loaded' error on macOS. In the article below, TipsMake will work with you to find.

For a quick test I made a sophisticated hello world C code, and tried it with that. In order to set the environment variable for the application to be executed, you need to specify DYLD_INSERT_LIBRARIES=[path to your dylib] in the command line. Here is how it looks like:

Executing my favourite note taker application, Bear (where I’m writing this right now) is also affected:

We can also see all these events in the log (as our dylib puts there a message):

There are two nice examples in the following blog posts about how to hook the application itself:

I will not repeat those, so if you are interested please read those.

Can you prevent this infection? Michael mentioned that you can do it by adding a RESTRICTED segment at compile time, so I decided to research it more. According to Blocking Code Injection on iOS and OS X there are three cases when this environment variable will be ignored:

setuid and/or setgid bits are set
restricted by entitlements
restricted segment

We can actually see this in the source code of dyld - this is an older version, but it’s also more readable: https://opensource.apple.com/source/dyld/dyld-210.2.3/src/dyld.cpp

The function pruneEnvironmentVariables will remove the environment variables:

If we search where the variable sRestrictedReason is set, we arrive to the function processRestricted:

This is the code segment that will identify the restricted segment:

Now, the above is the old source code, that was referred in the article above - since then it has evolved. The latest available code is dyld.cpp looks slightly more complicated, but essentially the same idea. Here is the relevant code segment, that sets the restriction, and the one that returns it (configureProcessRestrictions , processIsRestricted ):

It will set the gLinkContext.allowEnvVarsPath to false if:

The main executable has restricted segment
suid / guid bits are set
SIP is enabled (if anyone wonders CSR_ALLOW_TASK_FOR_PID is a SIP boot configuration flag, but I don’t know much more about it) and the program has the CS_RESTRICT flag (on OSX = program was signed with entitlements)

But! It’s unset if CS_REQUIRE_LV is set. What this flag does? If it’s set for the main binary, it means that the loader will verify every single dylib loaded into the application, if they were signed with the same key as the main executable. If we think about this it kinda makes sense, as you can only inject a dylib to the application that was developed by the same person. You can only abuse this if you have access to that code signing certificate - or not, more on that later ;).

There is another option to protect the application, and it’s enabling Hardened Runtime. Then if you want, you can specifically enable DYLD environment variables: Allow DYLD Environment Variables Entitlement - Entitlements. The above source code seems to be dated back to 2013, and this option is only available since Mojave (10.14), which was released last year (2018), probably this is why we don’t see anything about this in the source code.

For the record, these are the values of the CS flags, taken from cs_blobs.h

This was the theory, let’s see all of these in practice, if they indeed work as advertised. I will create an Xcode project and modify the configuration as needed. Before that we can use our original code for the SUID bit testing, and as we can see it works as expected:

Interestingly, in the past, there was an LPE bug from incorrectly handling one of the environment variables, and with SUID files, you could achieve privilege escalation, here you can read the details:OS X 10.10 DYLD_PRINT_TO_FILE Local Privilege Escalation Vulnerability | SektionEins GmbH

I created a complete blank Cocoa App for testing the other stuff. I also export the environment variable, so we don’t need to specify it always:

If we compile it, and run as default, we can see that dylib is injected:

To have a restricted section, on the Build Settings -> Linking -> Other linker flags let’s set this value:

If we recompile, we will see a whole bunch of errors, that dylibs are being ignored, like these:

Our dylib is also not loaded, so indeed it works as expected. We can verify the segment being present with the size command, and indeed we can see it there:

Alternatively we can use the otool -l [path to the binary] command for the same purpose, the output will be slightly different.

Next one is setting the app to have ( hardened runtime ), we can do this at the Build Settings -> Signing -> Enable Hardened Runtime or at the Capabilities section. If we do this and rebuild the app, and try to run it, we get the following error:

If I code sign my dylib using the same certificate the dylib will be loaded:

If I use another certificate for code signing, it won’t be loaded as you can see below. I want to highlight that this verification is always being done, it’s not a Gatekeeper thing.

Interestingly, even if I set the com.apple.security.cs.allow-dyld-environment-variables entitlement at the capabilities page, I can’t load a dylib with other signature. Not sure what I’m doing wrong.

To move on, let’s set the library validation (CS_REQUIRE_LV) requirement for the application. It can be done, by going to Build Settings -> Signing -> Other Code Signing Flags and set it to -o library. If we recompile and check the code signature for our binary, we can see it enabled:

And we get the same error message as with the hardened runtime if we try to load a dylib with different signer.

The last item to try would be to set the CS_RESTRICT flag, but the only thing I found about this is that it’s a special flag only set for Apple binaries. If anyone can give more background, let me know, I’m curious. The only thing I could do to verify it, is trying to inject to an Apple binary, which doesn’t have the previous flags set, not a