Microarchitectural Exploitation - CSE466 - Robert - 2024.11.27

The podcast discusses the challenges and complexities of microarchitectural exploitation, particularly in the context of a university course. Students are encouraged to utilize extra credit to mitigate the difficulty of the final modules, with the deadline for the microarchitectural exploitation module extended to the end of the semester. The discussion covers various attack types, including Spectre V1, Spectre V2, and Meltdown, providing insights into the mechanisms behind these exploits and how they can be leveraged.

Course Module Difficulty

• 00:00:27 The current microarchitecture exploitation module is considered difficult and has lived up to its reputation. It is arguably the hardest module in the course, followed by the next one, which is also difficult. Students are advised to use any extra credit earned earlier in the course to help with grades.

Server Load Impact

• 00:00:40 The performance of microarchitectural exploits can be significantly affected by the server load. Exploits are more difficult to pull off when the server is busy because of contention for CPU cores and cache resources. It's recommended to perform exploits during times of low CPU usage.

Synchronization Methods

• 00:05:06 Microsleep is a popular approach among students for synchronizing levels 1 through 5 in the microarchitecture exploitation module. It's a wrapper around the Nano sleep function, causing more memory accesses and introducing more noise in the cache. While functionally similar to Nano sleep, it can potentially complicate exploit efforts.

Side Channel Types

• 00:06:02 The microarchitecture exploitation module includes various side channel attack types. The first five levels involve a speculative side channel attack, similar to Spectre V1. Level 7 is a different side channel type, requiring a prefetch timing attack and a different approach than the first five levels.

CPU Core Pinning

• 00:08:11 The first five levels of the module randomly pin a process to a specific CPU core to ensure consistency in cache sharing. This is done automatically by the challenge process to ensure the exploit code runs on the same core as the challenge. Later levels, such as 8, 9, and 10, are Spectre-based and do not automatically pin the CPU.

Module Checkpoint Deadline

• 00:10:06 The checkpoint deadline for the current module has been extended to December 16th, the end of the semester, due to the module's difficulty. The extension provides students with an additional week to complete the checkpoint, although it still falls within the Thanksgiving break. The extension was granted because only about half of the students reached the previous checkpoint.

Spectre V1 vs. Spectre V2

• 00:14:30 Spectre V1 leverages conditional branches, where the CPU guesses whether a conditional jump will be taken, making it susceptible to training. Spectre V2 utilizes indirect branches, which involve jumps to memory locations determined during runtime. This necessitates training a different part of the CPU that tracks indirect jump targets.

Meltdown Exploitation

• 00:44:23 Meltdown exploits violate the security boundary between userland and the kernel by speculatively accessing kernel addresses. It bypasses the supervisor bit check, allowing userland code to speculatively access kernel memory, unlike Spectre, which relies on another process. This is demonstrated through a segfault handler example.

Kernel Module Access

• 01:07:07 Level 14 of the module involves accessing kernel memory using Meltdown and navigating page tables to find the flag within the physical memory map. The task struct, which holds information about processes, is pivotal. The strategy involves obtaining the task struct address, leaking the page table, and performing calculations to map the flag's virtual address to a physical memory address.