Meltdown: Reading Kernel Memory from User Space
Authors: Mortiz Lipp, Michael Schwarz, Daniel Gruss, et. al
Venue: arXiv
This paper is one of the massive mainstream security vulnerabilities exposed in 2018 for CPUs. The attack initially was independent of software vulnerabilities, and works even with the presence of KASLR/ASLR. The attack is based off speculative execution, which can result in what they call "transient instructions". These instructions begin execution, but do not finish so there is no change in architectural state. However, their are micro-architectural artifacts, which can be exploited via the Flush+Reload attack methodology. There are three main details worth explaining that are non-trivial:
1. Exception handling. When the program attempts to read from kernel memory, this will cause an exception. One way to handle this is via having the exception happen on a separate thread. However, an even more elegant solution is to put the attack in Intel TSX (transactional memory). In this case, an exception is not even raised, we are just notified the transaction fails. However, the micro-architectural state difference will still be present.
2. Getting into kernel code. Prior to this vuln, nearly all operating systems map the kernel into the user space memory in the upper portion of the address space. This allows for faster context switches as you do not have to switch page tables for every system call. By simply indexing into the upper address space, we can gain entry to the kernel.
3. Dealing with KASLR. The kernel code is randomized in the address space, however, it is only randomized with 40 bits. Assuming 8GB of memory, there are only 128 probe locations, which is easy enough.
The fix: See KAISER / KPTL: Kernel Page Table Isolation. Essentially, we can no longer map the kernel into the address space of user processes.
Full Text
Venue: arXiv
This paper is one of the massive mainstream security vulnerabilities exposed in 2018 for CPUs. The attack initially was independent of software vulnerabilities, and works even with the presence of KASLR/ASLR. The attack is based off speculative execution, which can result in what they call "transient instructions". These instructions begin execution, but do not finish so there is no change in architectural state. However, their are micro-architectural artifacts, which can be exploited via the Flush+Reload attack methodology. There are three main details worth explaining that are non-trivial:
1. Exception handling. When the program attempts to read from kernel memory, this will cause an exception. One way to handle this is via having the exception happen on a separate thread. However, an even more elegant solution is to put the attack in Intel TSX (transactional memory). In this case, an exception is not even raised, we are just notified the transaction fails. However, the micro-architectural state difference will still be present.
2. Getting into kernel code. Prior to this vuln, nearly all operating systems map the kernel into the user space memory in the upper portion of the address space. This allows for faster context switches as you do not have to switch page tables for every system call. By simply indexing into the upper address space, we can gain entry to the kernel.
3. Dealing with KASLR. The kernel code is randomized in the address space, however, it is only randomized with 40 bits. Assuming 8GB of memory, there are only 128 probe locations, which is easy enough.
The fix: See KAISER / KPTL: Kernel Page Table Isolation. Essentially, we can no longer map the kernel into the address space of user processes.
Full Text
Comments
Post a Comment