Bypassing KASLR on Apple Silicon: The SysBumps Attack

TLDR: Researchers have developed a novel side-channel attack called SysBumps that effectively bypasses Kernel Address Space Layout Randomization (KASLR) on Apple Silicon devices. By triggering speculative execution within specific system calls and using a TLB-based side-channel, an attacker can reliably leak the kernel base address in under three seconds. This research highlights a critical gap in hardware-level security for M-series chips and provides a clear path for future exploitation and mitigation.

Kernel Address Space Layout Randomization (KASLR) has long been the primary defense against memory corruption exploits. By randomizing the location of the kernel in memory, it forces attackers to find an information leak before they can reliably redirect execution flow. For years, we have relied on the assumption that if the kernel base is hidden, the system is significantly harder to compromise. That assumption just took a major hit.

The SysBumps research presented at Black Hat 2024 demonstrates that on Apple Silicon, KASLR is not the barrier we thought it was. The attack does not rely on traditional software-based memory leaks. Instead, it targets the microarchitectural design of the M-series chips themselves, specifically how they handle speculative execution during system calls.

The Mechanics of the Leak

At the heart of the attack is the interaction between speculative execution and the Translation Lookaside Buffer (TLB). When a user-space process invokes a system call, the CPU must transition into kernel mode. The researchers discovered that certain system calls, such as chdir or pathconf, can be coerced into speculatively accessing kernel memory even when the provided arguments are invalid.

Because the CPU speculatively executes these instructions before the privilege check is finalized, it leaves behind microarchitectural traces. Specifically, if the speculative access hits a valid kernel address, the TLB is updated with the translation. If the address is invalid, the TLB remains unchanged. This creates a binary oracle: by measuring the time it takes to access a specific memory range, an attacker can determine if that range contains a valid kernel mapping.

The researchers used the kpc performance monitoring unit to observe these TLB state changes. By systematically probing the memory space, they can identify the kernel base address with high precision. The process is remarkably fast, requiring only a few seconds to map the kernel memory layout, effectively rendering KASLR useless on affected devices.

From Theory to Execution

For a pentester or researcher, the implications are immediate. If you are performing a local privilege escalation engagement on a macOS device running on Apple Silicon, you no longer need to hunt for a complex memory leak to defeat KASLR. You can simply run the SysBumps exploit to obtain the kernel base address and proceed directly to exploiting your target vulnerability.

The researchers have released a proof-of-concept on GitHub that demonstrates this technique. The code is straightforward and highlights how easily these microarchitectural side channels can be turned into reliable primitives. During their demo, they showed the tool scanning the memory space and identifying the kernel base in roughly 2.4 seconds, with an average accuracy exceeding 96%.

Why This Matters for Your Workflow

This research serves as a reminder that hardware-level security is not a static target. As we move toward more complex architectures like ARM64, the assumptions we make about isolation boundaries are being challenged. For those of us working in bug bounty or red teaming, this means our toolkits need to evolve. We are no longer just looking for buffer overflows or use-after-free bugs in software; we are looking for ways to manipulate the CPU's own optimization features to our advantage.

The attack is particularly potent because it bypasses existing software-based mitigations. Even if an operating system implements Kernel Page Table Isolation (KPTI), the underlying hardware behavior can still be exploited if the CPU allows speculative access to kernel-space mappings.

The Path to Mitigation

Defending against this requires a shift in how we think about hardware and software integration. The researchers propose two primary mitigations. The first is a software-based approach: inserting serializing instructions like DSB or ISB on ARM64 before any conditional branch that could lead to a speculative access of sensitive memory. This forces the CPU to wait for the previous instructions to complete, effectively closing the speculative window.

The second, and more robust, approach is hardware-level partitioning. By separating the TLB entries for user-space and kernel-space, the CPU can prevent user-space processes from influencing or observing the state of kernel-space translations. While this would require a significant change in chip design, it is the only way to truly eliminate the contention that makes this side-channel possible.

Until hardware vendors address these microarchitectural flaws, we should expect to see more research focusing on these types of leaks. If you are auditing systems that rely on KASLR for security, start questioning the hardware. The next time you find yourself stuck behind a KASLR wall, remember that the CPU might be leaking the answer if you know how to ask the right questions.