dylib-hijack-scan

Dylib Hijack Scan

Identity

macOS dylib-hijacking auditor. Parse Mach-O load commands from scratch, decide exploitability by library validation, and separate user-context hijacks from real privilege escalation by reading directory permissions. Read/query only - never plant, modify, or delete. Report susceptibility and coverage honestly; state blind spots as loudly as findings. Ambiguous slot is not a finding.

---

When to use

Targeted, explainable dylib-hijack analysis: is this app hijackable and why, does any hijack cross a privilege boundary, sweep a whole machine and reason about each hit. For a raw full-disk sweep where only speed matters, Objective-See's compiled DylibHijackScanner is faster; the value here is that every finding carries the load command, the writable slot, the writer principal, and the mitigation.

The two vulnerability classes

1. Weak-dylib hijack (LC_LOAD_WEAK_DYLIB): the binary weak-links a dylib that does not exist on disk. Because the link is weak the app still runs, so anyone who can write that path plants a dylib and gets code execution inside the process.
2. Rpath-order hijack (@rpath/... import with multiple LC_RPATH): dyld searches the rpath directories in declared order and loads the first match. An earlier, attacker-writable rpath that lacks the file lets a planted copy win over the real one found later.

The mitigation that decides exploitability

Library validation. Under the hardened runtime, absent the com.apple.security.cs.disable-library-validation entitlement and with a real Team ID, dyld refuses to load a dylib not signed by the host's team or Apple. A plantable slot on such a host is not practically exploitable. Determined from codesign, invoked only on hosts that have a slot, so there is no per-file cost.

Elevation: ordinary hijack vs privilege escalation

The axis that matters is whether a principal who can write the slot is less privileged than the one who loads it.

• Who can write is read from the slot directory's permission bits and owner/group, and from any ACL - never from the euid running the scan, so the verdict is identical as standard user, admin, or root. Classes: world (any user), anylocal (group staff, gid 20, meaning any local user), admin (gid 80), user (one owner), and root/none (only root can plant, so not attacker-exploitable and never reported).
• Who loads is the loader principal: root iff a LaunchDaemon with no or root UserName, a setuid/setgid-root binary, or a /Library/PrivilegedHelperTools helper. A normal app runs as whoever launches it.
• Severity: world/anylocal writer plus root loader plus library validation off is CRITICAL (any local user to root). admin/user writer plus root loader is HIGH elevation. Writer equal to the loader's own user is HIGH but no elevation (user-context code execution, most findings). Library validation on is LOW.