A vulnerability has been exposed with third party code signing with macOS apps. Apparently, this vulnerability could have been exploited for over a decade. Josh Pitts from Okta has written a detailed article about the vulnerability.
Josh Pitts reports:
This vulnerability exists in the difference between how the Mach-O loader loads signed code vs how improperly used Code Signing APIs check signed code and is exploited via a malformed Universal/Fat Binary.
What is a Fat/Universal file?
A Fat/Universal file is a binary format that contains several Mach-O (an executable, dyld, or bundle) files with each targeting a specific native CPU architecture (example: i386, x86_64, or PPC).
Conditions for the vulnerability to work:
- The first Mach-O in the Fat/Universal file must be signed by Apple, can be i386, x86_64, or even PPC.
- The malicious binary, or non-Apple supplied code, must be adhoc signed and i386 compiled for an x86_64 bit target macOS.
- The CPU_TYPE in the Fat header of the Apple binary must be set to an invalid type or a CPU Type that is not native to the host chipset.
Without passing the proper SecRequirementRef and SecCSFlags, the code signing API (SecCodeCheckValidity) will check the first binary in the Fat/Universal file for who signed the executable (e.g. Apple) and verify no tampering via the cryptographic signature; then the API will check each of the following binaries in the Fat/Universal file to ensure the Team Identifiers match and verify no tampering via containing cryptographic signature but without checking the CA root of trust. The reason the malicious code, or “unsigned” code, must be i386, is that the code signing API has a preference for the native CPU architecture (x86_64) for code signing checks and will default to checking the unsigned code if it is x86_64.
Read More: Okta
OUR SECURITY SERVICES INCLUDE:
- Risk Assessments
- Penetration Testing
- Web Application Testing
- Security Awareness Training
- Managed SIEM
- Managed Security Services (MSSP)
- Security Consulting