mach_inject doesn't work on Apple processes in 10.14 unless filesystem SIP is disabled

[briankendall]

In macOS 10.11 through 10.13, you didn't have to disable all of SIP in order to use mach_inject in Apple's apps. All that was necessary was to disable debug protections, i.e. csrutil enable --without debug.

Starting in 10.14, in order to inject into Apple processes it is also necessary to disable filesystem protections as well, i.e. csrutil enable --without debug --without fs. With debug protections disabled but filesystem protections enabled, using mach_inject on an Apple process will lead to that process crashing, and using mach_inject on non-Apple processes still works. I thought this was odd as mach_inject doesn't modify the filesystem at all, much less a protected part of it.

I'm not sure if this counts as a bug or if there's anything to be done about it, but I figured I'd bring it up here.

[darshan-yadav]

Same is happening on non-apple processes also. Don't know how this can be fixed.

[briankendall]

@darshan-yadav Interesting. At one point I tested mach_inject in 10.14 with debug protections disabled and filesystem protections enabled and was able to get it to work with my own process. Not sure if that could be explained by the target being a binary I built myself, something changing between 10.14.0 and 10.14.2, or something else entirely.

[darshan-yadav]

Seems in new xcode. Processes are hardened by default and that causing the problem.

[briankendall]

@darshan-yadav I explicitly compiled my projects with hardened runtime disabled and still had this problem. Is there another setting or method for disabling it that fixes the issue?

[darshan-yadav]

@darshan-yadav I explicitly compiled my projects with hardened runtime disabled and still had this problem. Is there another setting or method for disabling it that fixes the issue?

One i can think is to compile with older version of X-Code. Other is check the CHFalgs value and see if
Any of following flags are set.
#define CS_ENFORCEMENT 0x00001000 /* require enforcement /
#define CS_RUNTIME 0x00010000 / Apply hardened runtime policies */

[briankendall]

I did a little bit more looking into this and found that when trying to inject into the Dock in 10.15 you get an error printed to the system console:

CODE SIGNING: process 692[Dock]: rejecting invalid page at address 0x10e522000 from offset 0x0 in file "<nil>" (cs_mtime:0.0 == mtime:0.0) (signed:0 validated:0 tainted:0 nx:0 wpmapped:0 dirty:1 depth:0)

So I'm guessing it's another facet of SIP, and even though it's not explicitly about being able to modify system files the filesystem protections cover it. I recently discovered that there are a few other areas where the filesystem protections affect the execution of processes, one of which being that apps with hardened runtime can't link to dynamic libraries using relative paths. For whatever reason disabling filesystem protections also disables that restriction. So it's not surprising then that there are other restrictions that having filesystem protections will impose.

Just for the hell of it I tried codesigning the binaries I was trying to inject and that changed the error to:

CODE SIGNING: process 600[Dock]: rejecting invalid page at address 0x10816a000 from offset 0x1000 in file "/path/to/bootstrap.dylib" (cs_mtime:1565055005.627355007 == mtime:1565055005.627355007) (signed:0 validated:0 tainted:0 nx:0 wpmapped:1 dirty:1 depth:2)

I'm not at all surprised it still didn't work, of course. I did find it interesting that I'm trying to inject into the Dock and it doesn't have hardened runtime enabled. However I'm sure the Dock is special-cased out the wazoo with Apple's security features.

I gather that there's no way to work around this, and maybe it's not that big of a deal since in order to inject in Apple processes you have to disable debugging protections anyway. But it would be nice if that was the only protection I needed to disable to modify Apple processes so I'm going to leave this issue open in the vain hope that there will someday be a workaround.