Block DYLD Environment Variable Injection

macOS uses the dynamic linker (dyld) to load libraries at runtime. Several environment variables can be used to inject malicious code into running processes without modifying the binary itself. This is a powerful attack technique that bypasses many security controls.

The most dangerous environment variables are:

• DYLD_INSERT_LIBRARIES: Forces dyld to load additional libraries into every process
• DYLD_LIBRARY_PATH: Hijacks library search paths to load malicious versions
• DYLD_FORCE_FLAT_NAMESPACE: Disables two-level namespace lookup, enabling symbol interposition

As documented by Csaba Fitzl at VirusBulletin 2021, these environment variables allow attackers to inject code into any process, including privileged system services. The injected code runs with the same privileges as the target process.

dyld strips these variables from any binary protected by System Integrity Protection (SIP) or launched with the hardened runtime, which covers Apple platform binaries and most modern signed third-party apps. Binaries without the hardened runtime remain vulnerable.

Some apps explicitly opt back into DYLD env var handling by adding hardened-runtime exception entitlements to their code signature:

• com.apple.security.cs.allow-dyld-environment-variables: tells dyld to honor DYLD_* variables despite the hardened runtime
• com.apple.security.cs.disable-library-validation: lets the process load libraries not signed by Apple or the same Team ID, which is what an injected DYLD_INSERT_LIBRARIES payload typically needs

These exceptions are common in apps that ship plugins, JIT compilers, or scripting hosts — Electron apps, IDEs, and debugging tools often request them. Apps with either entitlement are the prime targets for the rules below; author one rule per app you want to protect, using its specific signing ID. A CEL rule can then detect when the process is launched with a dangerous DYLD environment variable set and block execution.

These rules prevent any process from launching with dangerous DYLD environment variables set. You can deploy individual rules or use the combined rule that catches all dangerous DYLD variables.

Important considerations:

• Platform binaries are already protected by SIP and won't be affected
• Legitimate development use cases may need these variables (debugging, profiling)
• Consider using Workshop tags to exempt developer machines
• The combined rule is recommended for simplicity

Note: This does NOT protect against:

• Direct modification of libraries on disk
• Code injection via other mechanisms (thread injection, etc.)
• Attacks that set these variables before Santa loads

Legitimate uses of these environment variables:

• Software developers debugging applications with custom libraries
• Performance profiling tools using instrumentation libraries
• Development frameworks that inject debugging helpers
• Testing environments that need to override system libraries

Consider:

• Exempting developer machines using Workshop tags
• Creating approval workflows for development use
• Allowing specific development tools by their signing ID

1. Try to run a command with DYLD_INSERT_LIBRARIES: DYLD_INSERT_LIBRARIES=/path/to/lib.dylib /bin/ls (should be blocked)

2. Verify normal execution works: /bin/ls (should work)

3. Test with DYLD_LIBRARY_PATH: DYLD_LIBRARY_PATH=/tmp /bin/ls (should be blocked)

4. Check that legitimate apps run normally without these variables

Monitor CEL execution events for blocked DYLD variable usage. Any attempt to use these variables outside of approved development contexts is highly suspicious.

Investigation steps:

• Check which binary was attempting to launch
• Identify the parent process that set the environment variable
• Review the library path being injected
• Determine if this is legitimate development activity