CoreTrust is a new mechanism added in iOS 12 by Apple, aimed at preventing the “fake signing” technique used by tools such as ldid and jtool. It does this by ensuring any CMS blob attached to a mach-o contains a signature from Apple.
Heads up: This is developer-oriented research for those with advanced knowledge of programming, code signing techniques, attack vectors, security research, and jailbreak development.
Flow overview
- AMFI checks for the presence of a CMS blob in the MACF hook
_vnode_check_signature, failing if one is not found. - If a CMS Blob is present in the CSBlob, CoreTrust is called to validate it (
CTEvaluateAMFICodeSignatureCMS). - CoreTrust validation occurs before amfid validation.
Hashes in both static and dynamic trust caches are checked before CoreTrust is queried, thus making a “developer” jailbreak possible. However, this is both an unsustainable and impractical technique which should not be used for a public jailbreak.
Implications of this flow for jailbreaking
As CoreTrust now enforces the requirement of a CMS blob, this means that any potential bypass will likely require resigning of binaries.
Additionally, the order in which this happens is extremely important. As amfid is not called until after CoreTrust, hijacking amfid does not help in bypassing its functionality. However, this does mean that once CoreTrust validation is passed, the normal post-iOS 11 jailbreak flow should be possible.
CoreTrust implementation
CoreTrust stores the digest of Apple’s signing certificates in __CONST, meaning that they benefit from KPP/KTRR protection and they cannot be modified in memory.
Internally, CoreTrust sets “policies” to enforce upon CMS blobs, such as X509PolicySetFlagsForCommonName, which ensures the certificate’s common name is either “Apple iPhone Certification Authority” or “Apple Code Signing Certification Authority”. The entire certificate chain is iterated over, checking that it looks like Apple iPhone Certification Authority -> Apple Code Signing Certification Authority -> … If this check fails, CoreTrust validation fails and the result returned to AMFI, where further execution of is halted.
Attack vectors
There are a few attack vectors, but many are not scalable nor feasible.
- Use expired developer certificates with ldid/jtool. This approach is not feasible at scale, since it means that everything will need to be resigned to no longer use fake signing. Additionally, this violates Apple’s developer program’s Terms of Service and is impractical.
- CoreTrust bugs. Whilst this approach is scalable, it also means that more zerodays will have to be burnt per jailbreak, which is less sustainable.
Conclusion
We plan on doing more research on CoreTrust in the future, which will now be easier.
It is evident that CoreTrust will prove a real hurdle to jailbreakers, with limited effect on malware as they already possess valid code signatures. The principle behind CoreTrust appears sound, and adds a solid extra layer of security to Apple’s codesigning system.
Special thanks to @iBSparkes for technical proofreading.
