In the realm of cybersecurity, cross-cache attacks have emerged as an extremely popular technique for exploiting heap-based vulnerabilities. These attacks serve as the foundation for many well-known exploit methods, including Ret2dir and Ret2page. As Android strengthens its kernel mitigations, there is a growing trend towards proposing generic data-only exploitation methods, such as DirtyCred and Dirty Pagetable, to counteract mitigations like CFI and PAN. Notably, many of these generic exploitation methods heavily rely on the efficiency of cross-cache attacks. Let’s delve into the world of cross-cache attacks and explore their significance in the context of heap-based vulnerability exploits on Android.

Understanding Cross-Cache attacks

Cross-cache attacks are a sophisticated attack that targets the shared caching mechanisms in modern processors. These attacks exploit the ability of different processes to influence or observe the state of shared caches, like the CPU’s L1, L2, or L3 caches, to infer sensitive information from other processes running on the same hardware. Here’s how a cross-cache attack generally works:

Setup: The attacker sets up conditions to monitor or manipulate cache states. This involves priming the cache by accessing specific memory locations to fill the cache with data.

Victim access: The victim process then executes, potentially evicting some of the attacker’s data from the cache by loading its data.

Probe: After the victim’s operation, the attacker measures the time it takes to access their original data. If the data takes longer to access (a cache miss), the victim process has displaced some of the attacker’s data, indicating specific victim activity or data.

Analysis: The attacker can infer sensitive data such as cryptographic keys or user inputs by analysing the timing information and patterns of cache hits and misses.

Cross-cache attacks leveraged the unintended side channels created by processor caches’ design and shared nature. They are a significant concern in environments where multiple users or processes operate in a shared infrastructure, such as cloud computing platforms. Preventing such attacks often involves isolating sensitive processes, using hardware that supports enhanced security features, or implementing software mitigations that obscure the patterns of memory and cache usage.

Unleashing the cache attacks

Cross-cache attacks are a sophisticated form of attack that exploits use-after-free (UAF) vulnerabilities in the SLUB allocator. These attacks involve making the memory allocator reuse the memory of a victim object for an object with a different type, creating a type confusion that becomes a powerful attack primitive.

Use-after-free (UAF) vulnerabilities occur when a program continues to use a pointer after the memory it points to has been freed. This can lead to a variety of exploits, such as executing arbitrary code, because the freed memory might be allocated again for different data, and the old pointer can now reference the new, potentially maliciously crafted data.

Meanwhile, the SLUB allocator is one of the memory allocators used by the Linux kernel to manage slab allocations (a method for managing memory allocation for kernel objects). If a UAF vulnerability exists in how the SLUB allocator handles memory, it could be exploited directly (to execute arbitrary code or crash the system). Still, it wouldn’t typically be associated with a cross-cache attack unless there’s a particular and sophisticated attack vector that involves both cache timing and memory allocation behaviour.

Exploiting SLUB: address reuse and cross-cache attacks

As mentioned earlier, two primary ways exist to achieve such type of confusion within the kernel. The first method involves exploiting SLUB’s ability to reuse the address of a freed object for another object of a different type within the same slab cache. However, this approach is limited to slab caches containing objects of different types, such as the kmalloc caches. Additionally, the attacker is restricted to objects of the same size as the victim object.

The second method, a cross-cache attack, takes advantage of SLUB returning the page containing the victim object to the page allocator. The attacker then manipulates the page for a different slab cache or other objects containing attacker-controlled data. This grants the attacker access to all objects, not just those in the same size class as the target. It also enables targeting objects allocated from dedicated caches, such as struct files.

Black Hat Asia: cross-cache attacks on Android

So, we have now understood how cross-cache attacks can play a pivotal role in heap-based vulnerability exploitation on Android. Luckily, 4iMag had the chance to participate in this year’s Black Hat Asia 2024 conference, held in Singapore. Cyber professionals and companies worldwide gathered on one platform in two days to discuss different cyber topics that had significance for today’s day and age.

One particular session, held by Le Wu, a security researcher at Baidu, discussed the utilization of Dirty Pagetable, an effective cross-cache-based exploit method, to achieve privilege escalation on a Samsung Mobile device. While Dirty Pagetable has been previously demonstrated for rooting well-known Android devices, its utilization for attacking Samsung KNOX RKP remains unexplored.

During this presentation, Le Wu unveils new techniques that address the challenges encountered in cross-cache attacks. One of these techniques involves reclaiming the victim slab, even in scenarios where object allocation is restricted. Moreover, they have developed an elegant method for efficiently executing cross-cache attacks between slabs of different sizes. These techniques significantly enhance the effectiveness and success rate of cross-cache attacks on Android.

In addition to discussing Dirty Pagetable and its utilization in attacking Samsung KNOX RKP, a new technique for bypassing SELinux on Samsung devices was also revealed. SELinux is a crucial security measure on Android, and bypassing it presents a significant challenge. However, their newly developed technique overcomes this challenge, highlighting the potential vulnerabilities within SELinux and the importance of robust security measures.