Full Report
Code signing applications is an essential part of the macOS security model. Being able to bypass signing and verification steps would be a major flaw in the system, leading to users being at risk. Installer packages are the files used to install the actual package, which are typically signed as well. The installer packages are simply xar files. A xar file contains three parts: Header: A header of the fields. Includes a hash and the size of the next section. Table of Contents (TOC): A zlib compressed XML document that lists each file in the archieve. Heap: Holds the information about the package, signing information and a few other things. When viewing signed packages, two checks need to pass: calculated TOC hash is equal to the one stored on the heap and the signature + certificate belong to the TOC hash. Are the calculations of these the same? Not exactly! We have a C parsing bug! The checksum value form the XML document is loaded in as a 64-bit integer. For obtaining the TOC hash for validating the signature, a 32 bit integer is used. This difference in the offset value means that we can point the signature check to a different location! For instance, 0x1 0000 0000 would resolve to 0x1 0000 0000 for 64 bit but 0x0 for 32 bit. How do we actually do this? Take a legit and properly signed xar file. Change the checksum offset to a number larger than the 32-bit int max. Make the changes after this point. Write the TOC back to the file and compute the new TOC hash. This is the first check. Add padding to the heap until it's 32-bit max in sizes Place the new TOC hash at the heap offset of 32-bit max, leaving the original TOC hash at the heap offset. Why is this useful? First, System Integrity protection can be bypassed using this bug. By signing an Apple signed package with high TCC permissions, it can be bypassed to read sensitive information or modify the kernel. Secondly, the Gatekeeper (check against known malware) verification is broken too. They also found that it was possible to escalate privileges in several popular applications as well. The fix was to simply change the 32 bit int to a 64 bit int. A similar vulnerability was found in 2010 as well. Overall, a super fun post on the fun of parsing differences.
Analysis Summary
# Vulnerability: macOS .pkg Signature Verification Bypass via Integer Truncation
## CVE Details
- **CVE ID:** CVE-2022-42841
- **CVSS Score:** 7.8 (High) - *Estimate based on impact*
- **CWE:** CWE-197 (Numeric Truncation Error) / CWE-697 (Incorrect Comparison)
## Affected Systems
- **Products:** macOS (xar library and installer framework)
- **Versions:** macOS versions prior to macOS 13.1 (Ventura)
- **Configurations:** Systems processing signed Apple Installer packages (.pkg) or xar archives.
## Vulnerability Description
The vulnerability stems from a parsing discrepancy in how the `xar` library handles the Table of Contents (TOC) hash offset. When verifying a signed package, the system performs two checks:
1. **Integrity Check:** Compares the computed TOC hash against the hash stored on the "heap" at a specific offset.
2. **Signature Check:** Validates that the signature corresponds to the TOC hash at a specific offset.
The flaw lies in the data types used for these offsets. The integrity check correctly uses a **64-bit integer** to read the offset from the XML TOC. However, the signature validation logic utilized a **32-bit integer** for the same offset. By setting a checksum offset larger than the 32-bit maximum (e.g., `0x1 0000 0000`), an attacker can cause the signature check to "wrap around" and read from a different heap location (e.g., `0x0`) than the integrity check.
## Exploitation
- **Status:** PoC available; technically demonstrated to bypass security controls.
- **Complexity:** Medium (Requires creating a specifically crafted large xar/pkg file).
- **Attack Vector:** Local/User Interaction (Opening a malicious or modified installer package).
## Impact
- **Confidentiality:** High (Can be used to read sensitive information by bypassing TCC).
- **Integrity:** High (Bypasses System Integrity Protection (SIP) and Gatekeeper; allows modification of protected files or kernel).
- **Availability:** Medium (Potential for system instability through unauthorized modifications).
## Remediation
### Patches
- **macOS 13.1:** Apple patched the vulnerability by updating the signature verification offset variable from `uint32_t` to `uint64_t`.
- **Source Fix:** See Apple OSS [xar/commit/ae179cc73a1d854ff1283d48315bb8fb7bbf4dfe](https://github.com/apple-oss-distributions/xar/commit/ae179cc73a1d854ff1283d48315bb8fb7bbf4dfe).
### Workarounds
- There are no practical workarounds other than upgrading to a patched version of macOS. Users should only run installer packages from trusted sources.
## Detection
- **Indicators of Compromise:** Installer packages (.pkg) with unusually large sizes (padding used to reach the 4GiB/32-bit boundary) or packages where the XML `checksum/offset` is greater than `4294967295`.
- **Detection Methods:** Security tools can scan for xar files containing an `offset` value in the XML TOC that exceeds 32-bit integer limits.
## References
- **Vendor Advisory:** [https://support.apple.com/en-us/HT213532](https://support.apple.com/en-us/HT213532)
- **Technical Analysis:** [https://sector7.computest.nl/post/2023-01-xar/](https://sector7.computest.nl/post/2023-01-xar/)
- **Related Issue (2010):** CVE-2010-0055