Full Report
Introduction Some time in 2024, during a Project Zero team discussion, we were talking about how remote ASLR leaks would be helpful or necessary for exploiting some types of memory corruption bugs, specifically in the context of Apple devices. Coming from the angle of “where would be a good first place to look for a remote ASLR leak”, this led to the discovery of a trick that could potentially be used to leak a pointer remotely, without any memory safety violations or timing attacks, in scenarios where an attack surface can be reached that deserializes attacker-provided data, re-serializes the resulting objects, and sends the re-serialized data back to the attacker. The team brainstormed, and we couldn’t immediately come up with any specific attack surface on macOS/iOS that would behave this way, though we did not perform extensive analysis to test whether such attack surface exists. Instead of targeting a real attack surface, I tested the technique described here on macOS with an artificial test case that uses NSKeyedArchiver serialization as the target. Because of the lack of demonstrated real-world impact, I reported the issue to Apple without filing it in our bugtracker. It was fixed in the 31 Mar 2025 security releases. Links to Apple code in this post go to an outdated version of the code that hasn’t been updated in years, and descriptions of how the code works refer to the old unfixed version. I decided to write about the technique since it is kind of intriguing and novel, and some of the ideas in it might generalize to other contexts. It is closely related to a partial pointer leak and another pointer ordering leak that I discovered in the past, and shows how pointer-keyed data structures can be used to leak addresses under ideal circumstances.
Analysis Summary
# Vulnerability: Pointer Leaks via Pointer-Keyed Data Structures in Serialization Handlers
## CVE Details
- CVE ID: Not explicitly assigned/disclosed in the provided text, as the issue was reported without filing in the public bugtracker initially due to lack of demonstrated real-world impact.
- CVSS Score: Not calculated/provided.
- CWE: Likely related to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) or CWE-119 (Improper Restriction of Operations Within the Bounds of a Memory Buffer), depending on the final classification, although the core issue is an **Information Leak**.
## Affected Systems
- Products: macOS/iOS (Based on context mentioning Apple devices and `NSKeyedArchiver` testing on macOS).
- Versions: The fix was applied in the **31 Mar 2025 security releases**. Specific vulnerable versions prior to this date are not listed.
- Configurations: Susceptible surfaces involve code paths that deserialize attacker-provided data, re-serialize the resulting objects, and return the re-serialized data to the attacker (e.g., complex serialization/deserialization routines).
## Vulnerability Description
This vulnerability describes a theoretical local or remote **Address Space Layout Randomization (ASLR) leak technique**. The flaw exists in scenarios where an application processes untrusted input via a mechanism that involves:
1. Deserializing attacker-controlled data.
2. Re-serializing the resulting objects (or data structures containing them).
3. Sending this re-serialized output back to the attacker.
The technique exploits how pointer-keyed data structures (like certain hash maps or dictionaries, specifically tested using `NSKeyedArchiver` serialization) use memory addresses (pointers) as keys or parts of the keying structure. By carefully controlling the input data and observing the resulting serialization output (which implicitly reveals ordering or aspects of the internal hash state tied to the pointers), an attacker can leak memory addresses (partial pointers) without relying on memory safety violations or timing attacks.
## Exploitation
- Status: **Theoretical only.** The technique was tested on an artificial test case using `NSKeyedArchiver` on macOS. No specific real-world attack surface was identified or targeted, and it was not exploited in the wild. The researcher reported it without filing in the standard bugtracker due to the lack of demonstrated immediate impact.
- Complexity: **Medium to High (Theoretical context).** Requires understanding of serialization internals and pointer-keyed data structures. If a suitable re-serialization attack surface exists, the information leak itself is passive and does not require timing attacks.
- Attack Vector: Potentially **Network** or **Local**, depending on where the vulnerable deserialization/re-serialization surface is exposed (e.g., a network service processing uploaded documents).
## Impact
- Confidentiality: **High (Potential ASLR Bypass).** Successful exploitation of this technique could lead to reliable remote ASLR bypasses, significantly lowering the complexity of executing subsequent memory corruption exploits.
- Integrity: **Low (Directly).** The flaw is an information leak, not a direct corruption mechanism.
- Availability: **Low (Directly).** The technique does not inherently cause denial of service, although the initial hashDoS background discussed historical DoS vectors related to hash collisions.
## Remediation
### Patches
- Apple fixed the underlying implementation issues in the **31 Mar 2025 security releases**. Users should update to versions containing these patches.
### Workarounds
- **Avoid address-based keys:** The most robust mitigation suggested is to avoid using object addresses directly as lookup keys in data structures.
- **Use Keyed Hashing:** Alternatively, object addresses/pointers should be hashed using a keyed hash function. This reduces the resulting pointer leak potential to that of a pointer equality oracle, which is significantly less useful than a full address leak.
## Detection
- **Indicators of Compromise:** Since this exploit is dependent on specific application logic involving deserialization/re-serialization cycles returning data to the attacker, monitoring for unusual or excessive data serialization/network egress correlating with untrusted input processing might serve as a heuristic indicator.
- **Detection Methods and Tools:** Standard memory corruption detectors are unlikely to trigger, as this is an information leak. Detection relies on application security monitoring focusing on input validation and data flow analysis for serialization pipelines.
## References
- Vendor Advisories: [Apple Security Release Advisory for 31 Mar 2025](https://support.apple.com/en-us/122373) (Placeholder based on text reference).
- Relevant links - defanged:
- Project Zero Article: hxxps://projectzero.google/2025/09/pointer-leaks-through-pointer-keyed.html