Overview
Google Project Zero has once again provided important insight into Apple’s security model. Security researcher Jann Horn discovered a novel ASLR (Address Space Layout Randomization) bypass approach that takes use of deterministic characteristics in Apple’s serialization framework, notably NSKeyedArchiver and NSKeyedUnarchiver.
Unlike classic memory corruption vulnerabilities, this method allows attackers to leak memory addresses without destroying the system or using timing-based side channels.
What is ASLR and Why It Matters
ASLR is a key memory protection mechanism that randomizes memory address layouts, making it difficult for attackers to guess where specific code or data sits.
Bypassing ASLR can expose memory addresses for important system objects, allowing attackers to chain additional vulnerabilities like RCE (Remote Code Execution) or privilege escalation.
This new technique demonstrates that ASLR can be compromised even when there is no direct problem present – merely by using predictable serialization semantics.
How the Vulnerability Works
1. Root Cause: Serialization Determinism
The issue stems from the way Apple’s NSKeyedArchiver/NSKeyedUnarchiver handle NSDictionary objects during serialization.
When applying:
- Deserialize the attacker-controlled input.
- Re-serialize, and
- Return the serialized result.
they unintentionally expose memory layout information.
2. Singleton Behavior: NSNull as a Leak Oracle
Apple’s NSNull object (a singleton) is extremely important.
Its hash value equals its memory address, and because it occupies a fixed area in shared memory, it can be used as an oracle to determine its address.
3. Predictable Hashing with NSNumber Keys
Attackers can use NSNumber keys to create harmful serialized data.
These keys hash reliably, and NSDictionary utilizes prime-numbered bucket counts to preserve insertion order.
Observing where NSNull falls during reserialization allows attackers to calculate hash_code% num_buckets, disclosing sections of the memory address.
4. Reconstructing Memory Address
The attacker can recreate the NSNull object’s complete pointer address by repeating the attack with different hash table sizes (eWhile no commercial app has been identified to use this same deserialize-reserialize-return pattern, the study supports the theoretical capability and risk..g., 23, 41, 71, and 1087 buckets) and using the Extended Euclidean Algorithm.
Proof-of-Concept Demonstration
Horn demonstrated this attack in a controlled setting:
- The attacker provides around 50 KiB of serialized information (an NSArray containing numerous NSDictionary objects).
- The victim re-serializes and returns the data.
- The attacker uses bucket positions to determine the leaked address.
While no commercial app has been identified to use this same deserialize-reserialize-return pattern, the study supports the theoretical capability and risk.
Impact and Security Implications
This discovery shows that:
- ASLR bypasses can occur without causing memory damage.
- Due to deterministic behavior, serialization frameworks have the potential to leak sensitive data.
- Attackers could use these flaws in chained exploits that need ASLR bypass.
Apple’s Response and Fix
Apple patched the issue in its March 31, 2025 security update.
Although no immediate attack surface was found, the fix included:
- Removing pointer-based hash values,
- Improving serialization logic, and
- Enhancing framework unpredictability.
Recommended Best Practices
Horn’s recommendations serve as valuable guidelines for all developers:
- Avoid using memory addresses as hash values
- Implement strict allowlists during deserialization
- Don’t reserialize attacker-controlled input
- Never expose serialized outputs across trust boundaries
- Regularly update frameworks to patch deterministic flaws
These principles align with secure coding standards for preventing deserialization attacks and information disclosure.