macOS Code Signing

Basic Information

Mach-o binaries contains a load command called LC_CODE_SIGNATURE that indicates the offset and size of the signatures inside the binary. Actually, using the GUI tool MachOView, it's possible to find at the end of the binary a section called Code Signature with this information:

The magic header of the Code Signature is 0xFADE0CC0. Then you have information such as the length and the number of blobs of the superBlob that contains them. It's possible to find this information in the source code here:

Common blobs contained are Code Directory, Requirements and Entitlements and a Cryptographic Message Syntax (CMS). Moreover, note how the data encoded in the blobs is encoded in Big Endian.

Moreover, signatures cloud be detached from the binaries and stored in /var/db/DetachedSignatures (used by iOS).

Code Directory Blob

It's possible to find the declaration of the Code Directory Blob in the code:

Note that there are different versions of this struct where old ones might contain less information.

Signing Code Pages

Hashing the full binary would be inefficient and even useless if when it's only loaded in memory partially. Therefore, the code signature is actually a hash of hashes where each binary page is hashed individually. Actually, in the previous Code Directory code you can see that the page size is specified in one of its fields. Moreover, if the size of the binary is not a multiple of the size of a page, the field CodeLimit specifies where is the end of the signature.

Entitlements Blob

Note that applications might also contain an entitlement blob where all the entitlements are defined. Moreover, some iOS binaries might have their entitlements specific in the special slot -7 (instead of in the -5 entitlements special slot).

Special Slots

MacOS applications doesn't have everything they need to execute inside the binary but they also use external resources (usually inside the applications bundle). Therefore, there are some slots inside the binary who will be containing the hashes of some interesting external resources to check they weren't modified.

Actually, it's possible to see in the Code Directory structs a parameter called nSpecialSlots indicating the number of the special slots. The there isn't a special slot 0 and the most common ones (from -1 to -6 are):

  • Hash of info.plist (or the one inside __TEXT.__info__plist).

  • Has of the Requirements

  • Hash of the Resource Directory (hash of _CodeSignature/CodeResources file inside the bundle).

  • Application specific (unused)

  • Hash of the entitlements

  • DMG code signatures only

  • DER Entitlements

Code Signing Flags

Every process has related a bitmask known as the status which is started by the kernel and some of them can be overridden by the code signature. These flags that can be included in the code signing are defined in the code:

Note that the function exec_mach_imgact can also add the CS_EXEC_* flags dynamically when starting the execution.

Code Signature Requirements

Each application store some requirements that it must satisfy in order to be able to be executed. If the application contains requirements aren't satisfied by the application, it won't be executed (as it has probably been altered).

The requirements of a binary use a special grammar which is a stream of expressions and are encoded as blobs using 0xfade0c00 as the magic whose hash is stored in a special code slot.

The requirements of a binary can be seen running:

Note how this signatures can check things like certification information, TeamID, IDs, entitlements and many other data.

Moreover, it's possible to generate some compiled requirements using the csreq tool:

It's possible to access this information and create or modify requirements with some APIs from the Security.framework like:

Checking Validity

  • Sec[Static]CodeCheckValidity: Check the validity of SecCodeRef per Requirement.

  • SecRequirementEvaluate: Validate requirement in certificate context

  • SecTaskValidateForRequirement: Validate a running SecTask against CFString requirement.

Creating and Managing Code Requirements

  • SecRequirementCreateWithData: Creates a SecRequirementRef from binary data representing the requirement.

  • SecRequirementCreateWithString: Creates a SecRequirementRef from a string expression of the requirement.

  • SecRequirementCopy[Data/String]: Retrieves the binary data representation of a SecRequirementRef.

  • SecRequirementCreateGroup: Create a requirement for app-group membership

Accessing Code Signing Information

  • SecStaticCodeCreateWithPath: Initializes a SecStaticCodeRef object from a file system path for inspecting code signatures.

  • SecCodeCopySigningInformation: Obtains signing information from a SecCodeRef or SecStaticCodeRef.

Modifying Code Requirements

  • SecCodeSignerCreate: Creates a SecCodeSignerRef object for performing code signing operations.

  • SecCodeSignerSetRequirement: Sets a new requirement for the code signer to apply during signing.

  • SecCodeSignerAddSignature: Adds a signature to the code being signed with the specified signer.

Validating Code with Requirements

  • SecStaticCodeCheckValidity: Validates a static code object against specified requirements.

Additional Useful APIs

  • SecCodeCopy[Internal/Designated]Requirement: Get SecRequirementRef from SecCodeRef

  • SecCodeCopyGuestWithAttributes: Creates a SecCodeRef representing a code object based on specific attributes, useful for sandboxing.

  • SecCodeCopyPath: Retrieves the file system path associated with a SecCodeRef.

  • SecCodeCopySigningIdentifier: Obtains the signing identifier (e.g., Team ID) from a SecCodeRef.

  • SecCodeGetTypeID: Returns the type identifier for SecCodeRef objects.

  • SecRequirementGetTypeID: Gets a CFTypeID of a SecRequirementRef

Code Signing Flags and Constants

  • kSecCSDefaultFlags: Default flags used in many Security.framework functions for code signing operations.

  • kSecCSSigningInformation: Flag used to specify that signing information should be retrieved.

Code Signature Enforcement

The kernel is the one that checks the code signature before allowing the code of the app to execute. Moreover, one way to be able to write and execute in memory new code is abusing JIT if mprotect is called with MAP_JIT flag. Note that the application needs a special entitlement to be able to do this.

cs_blobs & cs_blob

cs_blob struct contains the information about the entitlement of the running process on it. csb_platform_binary also informs if the application is a platform binary (which is checked in different moments by the OS to apply security mechanisms like to protect the SEND rights to the task ports of these processes).

References

Last updated