[MacPorts] #66358: sip-workaround no longer works on macOS 13 Ventura due to new security features
MacPorts
noreply at macports.org
Wed Jul 5 02:43:50 UTC 2023
#66358: sip-workaround no longer works on macOS 13 Ventura due to new security
features
-------------------------+---------------------
Reporter: reneeotten | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: base | Version:
Resolution: | Keywords: ventura
Port: |
-------------------------+---------------------
Comment (by jrabinow):
{{{
macOS 13.3 22E252 arm64
Xcode 14.3 14E222b
}}}
As far as I can tell, `amfi_check_dyld_policy_self` isn't being issued as
per
- /usr/bin/syscallbypid.d
- /usr/bin/syscallbyproc.d
- /usr/bin/syscallbysysc.d
and no new process is being executed as per `/usr/bin/newproc.d`.
`execsnoop` does see `make` but when I tried tracing it with `dtruss -W` I
got `failed to grab pid 19387: (null)` which makes me think it's too
short-lived and/or doesn't get initalized properly. So somewhere between
execsnoop and newproc.d the process gets killed off.
-----------------
I tried to strip the signature from make as described above, it's still
getting killed:
{{{
$ codesign --remove-signature make
$ codesign -vv make
make: code object is not signed at all
In architecture: arm64e
[Exit 1]
$ ./make
Killed: 9
[Exit 137 (KILL)]
}}}
I also tried signing make with my own custom signature and it still didn't
launch.
----------------------
Moving onto provenance:
I can see the provenance on make. Worth noting it didn't appear
immediately (less than 1h of playing around with it, digging into this and
a few other things). When I tried checking and copying a `make2` to tmp,
the provenance appeared right away though, so go figure if I didn't mess
up somehow.
{{{
$ /bin/ls -l@ /tmp/make
-rwxr-xr-x@ 1 julien wheel 132017 Jul 4 16:09 /tmp/make
com.apple.provenance 11
$ xattr -px com.apple.provenance ./make
01 00 00 5D 19 F7 5D 19 6C 9E A9
}}}
From: https://eclecticlight.co/2023/03/13/ventura-has-changed-app-
quarantine-with-a-new-xattr/
`The xattr is protected by SIP, so can’t be removed unless the app is
copied to another volume.` I haven't tried removing it.
Also for what it's worth, I asked chatgpt for a summary of what are
cdhashes and checked it against apple's docs (links below). It had this to
say:
{{{
A CDHash, short for Code Directory Hash, is a cryptographic hash value
associated with a binary executable file on macOS systems. It is used as a
security measure to verify the integrity and authenticity of the code
before it is executed.
When a binary is signed with an Apple Developer certificate, the signing
process generates a CDHash for the code. This hash is derived from the
code directory, which contains a list of the file offsets and sizes for
each segment of the executable. By calculating the CDHash, the system can
ensure that the code has not been tampered with or modified since it was
signed.
The CDHash is stored in the code signature of the binary and is checked by
the Gatekeeper service on macOS when an application is launched. If the
CDHash does not match the expected value, indicating that the binary has
been altered, Gatekeeper will prevent the application from running,
providing an additional layer of security against malicious software.
It's worth noting that the CDHash is just one component of the code
signing process on macOS, which includes other checks.
}}}
Also see:
-
https://developer.apple.com/documentation/endpointsecurity/es_process_t/3228976-cdhash
- https://developer.apple.com/documentation/technotes/tn3126-inside-code-
signing-hashes
If this is what is causing issues, I'd assume the following approximate
setup:
- the provenance is stored in the binary's extended attributes and can't
be removed because SIP.
- this provenance points to an entry in the ExecPolicy database in
provenance_tracking table. I tried finding it but couldn't.
- The execpolicy database would allow the OS (going by opensnoop's output,
most likely syspolicyd) to compare the calculated cdhash against the
cdhash stored in the provenance_tracking table.
- The cdhash is used to seal the binary. If the calculated values don't
match the cdhash, the OS (again, most likely syspolicyd) sends kill -9
Worth noting that I tried finding make in
/var/db/SystemPolicyConfiguration/ExecPolicy provenance_tracking table but
couldn't find anything that seemed relevant. I rebooted my computer in
case the db was only flushed to disk on process restart, still no dice. I
didn't see anything relating to /usr/bin in there either, so I'm still
missing something and I'm not sure if this ExecPolicy database is
relevant. Maybe provenance is used by something else? Maybe, as chatgpt
suggests, it's another mechanism entirely?
I'd suggest the way forward on this one would be to open up execsnoop
script, repurpose it to have it attach to a new process named `make`,
`gatekeeper` (assuming it runs in its own process) or `syspolicyd` and
have it observe everything that happens to it. I've barely looked at
gatekeeper, and https://eclecticlight.co/2023/03/16/what-is-macos-ventura-
doing-tracking-provenance/ suggests to me that gatekeeper might run even
before syspolicyd gets involved at all.
Also I'd be curious if anyone can repro the copying of a binary out of
/usr/bin without the 'provenance' xattr, like I initially got and like
kencu's comment above suggests. Can make run at that time? If you wait for
some time, does the provenance appear on its own? If so, does the binary
start getting killed then?
Question from a complete newbie, why do we need to use Apple's binaries at
all? Could macports not ship its own binaries and bootstrap from there,
reminescent of the gcc bootstrapping process?
--
Ticket URL: <https://trac.macports.org/ticket/66358#comment:31>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list